Codex Desktop history thread fails to open when old messages contain directive attributes with Windows backslash paths

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.3673.0

What subscription do you have?

Pro 20x, Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Environment:

• App: Codex Desktop
• OS: Windows
• Session storage: %USERPROFILE%\.codex\sessions\...

Summary:
Some historical Codex Desktop threads became invisible or failed to open. The underlying JSONL session files were still present and readable. The failure appears to be in the Desktop renderer / Markdown directive parser when rendering historical assistant messages that contain Codex directives whose attributes include Windows paths with backslashes.

What steps can reproduce the bug?

Root cause observed locally:
Historical assistant messages contained directives such as git stage / commit directives with cwd attributes pointing to Windows paths using backslashes. When those messages were rendered by Codex Desktop, the directive parser produced an error similar to:

invalid syntax at line 1 col 5: cwd="<drive>:\path\to\workspace"

Impact:

• Affected threads could appear missing or fail to open in Codex Desktop history.
• The raw session JSONL data was still present.
• Rebuilding / repairing indexes alone did not fully solve it when the renderer encountered the offending historical text.
• Replacing directive attribute paths from Windows backslash form to forward-slash form made affected threads readable again.

What is the expected behavior?

Local repair that worked:
A narrow JSONL repair converted directive attributes only, for attributes like cwd, cwds, and file, from Windows backslash paths to forward-slash paths.

Example transformation:

• from cwd="<drive>:\path\to\workspace"
• to cwd="<drive>:/path/to/workspace"

This repaired 138 session JSONL files and about 5530 directive path attributes. After repair:

• reverse scan for remaining raw Windows directive path attributes returned 0
• JSON probe errors returned 0
• sampled thread/read calls succeeded

Important secondary issue:
The repair thread itself became the only remaining broken thread because its final answer included the original offending directive example as explanatory text. That means the renderer can be triggered even by explanatory inline text containing a directive-shaped string, not only by actual emitted directives.

Expected behavior:
Codex Desktop should safely render historical messages containing directive-shaped text with Windows paths, especially inside inline code / code fences / explanatory text. At minimum, one malformed directive should not break opening the entire thread.

Actual behavior:
A thread can fail to render/open when a historical message includes a directive-shaped string whose attribute contains a Windows backslash path.

Suggested fix:

• Directive parser should either tolerate Windows backslashes in quoted attributes, or
• Only parse directives in intended structural positions, not arbitrary inline explanatory text, or
• Gracefully render malformed directives as plain text instead of failing the whole thread.

Additional information

_No response_