Codex desktop: historical conversations fail to open after rendering ::git-* directive lines with Windows backslash paths

[aaaaa-ozo23]

Codex desktop: historical conversations fail to open after rendering ::git-* directive lines with Windows backslash paths

Summary

Some existing Codex Desktop conversations in a project failed to open after a version update/check cycle. The conversation list was still visible, but opening affected conversations showed only:

糟糕，出错了

Retrying and checking for updates did not recover the affected conversations.

Local investigation suggests this is not JSONL corruption and not an incomplete local app update. The affected historical session records contained assistant text with standalone internal-looking ::git-*{...} directive lines whose cwd attribute used normal Windows backslash paths, for example D:\.... The current Codex Desktop renderer/parser appears to try to parse those historical text lines as directives and then crashes the conversation page on invalid directive syntax.

Environment

• OS: Windows
• Codex Desktop package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
• Appx package version: 26.513.3673.0
• Package install location:
  • C:\Program Files\WindowsApps\OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
• Package status from Get-AppxPackage:
  • SignatureKind: Store
  • Status: Ok

User-visible symptom

1. Project conversations appeared normally in the left sidebar.
2. Opening some older project conversations failed.
3. The main panel showed:
   • 糟糕，出错了
   • buttons: 检查更新, 重试
4. 重试 did not recover.
5. 检查更新 did not recover.
6. Other conversations without the offending lines could still open.

One affected conversation was named:

• 执行第二轮bug修复

Local evidence from Codex logs

Codex Desktop logs under this path contained repeated page-render errors:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\16\...

Relevant error text:

invalid syntax at line 1 col 5: cwd="D:\CS_basics\Hw6-AI-co-worker"
name=LocalConversationPage

This points to parsing of the directive argument string, not to a missing session file or malformed JSONL.

Offending session content pattern

The affected session file was a normal JSONL file under:

%USERPROFILE%\.codex\sessions\2026\05\14\rollout-2026-05-14T23-33-05-019e271e-b927-7a50-b8e9-367993ca2d52.jsonl

The session JSONL itself parsed successfully. The problem was inside assistant text fields. The final assistant message contained standalone lines similar to:

::git-stage{cwd="D:\CS_basics\Hw6-AI-co-worker"}
::git-commit{cwd="D:\CS_basics\Hw6-AI-co-worker"}
::git-push{cwd="D:\CS_basics\Hw6-AI-co-worker" branch="2251210697_xuhanyu"}

After replacing those standalone directive lines with plain text, the conversation opened normally again.

Why this looks like a rendering/parser compatibility bug

• The affected conversations were not newly created on the day the issue appeared.
• They already contained the problematic text in historical assistant messages.
• The failure appeared when the current Codex Desktop version tried to open/render them.
• The JSONL file could still be read and validated line by line with PowerShell ConvertFrom-Json.
• Removing or replacing only the standalone directive text restored the conversation.
• Local package integrity checks did not show evidence of an incomplete or corrupted update.

Current hypothesis:

1. Older conversations stored standalone ::git-* directive-looking lines as assistant text.
2. Current Codex Desktop attempts to interpret those lines as app directives while rendering historical messages.
3. Normal Windows paths with backslashes inside directive attributes are rejected by the parser.
4. The parser error is not isolated to the single message. Instead, the whole LocalConversationPage fails to render.

Targeted repair script used for the first affected conversation

Before running the repair, Codex Desktop was fully closed. The script also refused to proceed if Codex or codex processes were still running.

Script file:

repair-codex-thread-019e271e.ps1

What it did:

1. Targeted one known broken session JSONL file.
2. Checked whether Codex was still running.
3. Created a timestamped .bak-YYYYMMDD-HHMMSS backup next to the session file.
4. Replaced the exact directive block with plain text:

Git 操作已完成：stage / commit / push。

5. Re-read every line and validated it with ConvertFrom-Json.
6. Reported:
   • repaired file path
   • backup path
   • number of replaced blocks
   • number of validated JSONL lines

Result:

• The conversation 执行第二轮bug修复 opened normally after the repair.

Batch scan and repair script

A second script was created to scan all local Codex session JSONL files for the same standalone directive pattern.

Script file:

repair-codex-standalone-git-directives.ps1

Dry-run command:

powershell -ExecutionPolicy Bypass -File .\repair-codex-standalone-git-directives.ps1 -ScanOnly

Repair command:

powershell -ExecutionPolicy Bypass -File .\repair-codex-standalone-git-directives.ps1

Important safety behavior:

• Scans %USERPROFILE%\.codex\sessions recursively.
• Ignores backup files whose names already contain .bak-*.
• Looks for standalone Windows-path directive lines matching:

(?m)^::git-(stage|commit|push|create-branch|create-pr)\{cwd="[A-Za-z]:\\[^\r\n]*\}\r?\n?

• Reads %USERPROFILE%\.codex\session_index.jsonl to map thread IDs to conversation names.
• In -ScanOnly mode, it only reports matching sessions and does not modify anything.
• In repair mode, it refuses to run while Codex is open.
• For each affected file:
  • creates a timestamped backup;
  • removes only the matched standalone directive lines from JSON text fields;
  • writes UTF-8 without BOM;
  • validates every JSONL line after writing.

Initial scan after repairing the first conversation found additional historical project conversations containing the same pattern:

Conversation	Thread ID	Hits
同步文档并推送 v1.0.3	019e1526-1162-73c1-969b-b1c5fde21da3	6
美化 LAN 界面	019e1a2f-f398-75b1-a415-c59193f3484a	4
执行第一轮 bug 修复	019e220e-e36a-75c1-a216-c2ccd0dd2f02	6

Later scan status on the current machine:

Matched sessions:
ThreadName: 修复对话无法打开
ThreadId: 019e300b-89b3-7113-a92d-a788a35d6e6f
Hits: 2

Note: the current diagnostic conversation itself contains literal examples of the problematic lines, so this may be a diagnostic false positive unless that conversation also fails to open later.

Codex installation integrity checks performed

The goal was to rule out a failed or partial update.

Appx package check

Command:

Get-AppxPackage -Name OpenAI.Codex |
  Select-Object Name,PackageFullName,Version,InstallLocation,SignatureKind,Status |
  Format-List

Observed:

Name            : OpenAI.Codex
PackageFullName : OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
Version         : 26.513.3673.0
InstallLocation : C:\Program Files\WindowsApps\OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
SignatureKind   : Store
Status          : Ok

Manifest check

Parsed AppxManifest.xml:

IdentityName: OpenAI.Codex
Publisher: CN=50BDFD77-8903-4850-9FFE-6E8522F64D5B
Version: 26.513.3673.0
ProcessorArchitecture: x64
DisplayName: Codex
Executable: app/Codex.exe
EntryPoint: Windows.FullTrustApplication

File hash spot checks

app\Codex.exe
SHA256: 8B4200D4B36EFF2E53EC25B90509AECB8D532E2C05C182FA2B3BADBCF081BD5C

app\resources\codex.exe
SHA256: F6CD8E1C474B9188C1DC1685D268EAA9F59A0E4B8434B048BDC6CE7B1C70A442

app\resources\app.asar
SHA256: A63A07BAFBB54C9F18F5FB03E5E0EA8260B53D48B9D488B64F3196EC4D930DE5

AppxManifest.xml
SHA256: 17B0BB22BF66B193DBC5ED6B8C5CC2640EB2DDBC6358EAAD5AFE7060ED6F2442

AppxBlockMap.xml
SHA256: D9B4866EBFF0FE49C59F1B0CCE11AB19F1A83631FA6F411E3907425C666FC940

AppxSignature.p7x
SHA256: F10FB431267B001077AC7D2C1099BD396D3D4B5C402DDDC1C0F0E09DDB479DD8

Authenticode checks

Observed:

app\Codex.exe: NotSigned
app\resources\codex.exe: Valid, signer OpenAI OpCo, LLC
AppxSignature.p7x: Valid, Microsoft Marketplace CA

The unsigned app\Codex.exe did not by itself indicate a broken install, because the MSIX/Appx package signature was valid and the package status was Ok.

Appx block map verification

Observed:

Block map file entries: 871
Files present and size-matched: 871
Whole-file b4 hashes checked: 122
No mismatch/read error found
Entries without whole-file hash: 749

Runtime log package path

Codex logs showed runtime execution from:

C:\Program Files\WindowsApps\OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Conclusion from integrity checks:

• The installed Codex package appears intact.
• The issue is more likely a renderer/parser regression or compatibility issue with historical conversation content than a locally corrupted update.

Expected behavior

Codex Desktop should not make an entire historical conversation impossible to open because a previous assistant message contains directive-looking text.

Safer behavior would be one of:

• render malformed/legacy directive-looking text as plain text;
• ignore malformed directives while preserving the rest of the message;
• show a localized per-message warning instead of crashing the whole conversation page;
• support normal Windows backslash paths in directive attributes;
• provide an automatic migration/repair for affected local session files.

Actual behavior

Opening a conversation with these historical lines causes the whole local conversation page to fail:

糟糕，出错了

The local log reports:

invalid syntax at line 1 col 5: cwd="D:\CS_basics\Hw6-AI-co-worker"
name=LocalConversationPage

Minimal reproduction hypothesis

On Windows, create or load a local Codex conversation whose assistant text contains a standalone line like:

::git-stage{cwd="D:\example\repo"}

Then reopen that conversation in Codex Desktop version 26.513.3673.0.

Expected result:

• Conversation opens and the text is either rendered literally or ignored safely.

Observed result on this machine:

• The conversation page fails to render.

Workaround used locally

1. Fully quit Codex Desktop.
2. Back up the affected session JSONL file.
3. Remove or replace only the standalone ::git-* directive-looking lines with Windows backslash paths.
4. Validate every JSONL line.
5. Reopen Codex.

This restored at least one previously broken conversation.

Request to maintainers

Please consider making the local conversation renderer tolerant of malformed or legacy directive-looking text in historical messages. In particular:

1. Do not crash LocalConversationPage when directive parsing fails.
2. Treat malformed directive-looking text as plain Markdown/text.
3. Support Windows paths with backslashes or clearly escape them before storing/rendering.
4. Provide a migration/repair path for existing local session JSONL files already containing these lines.

I can provide additional redacted logs or session snippets if needed.