Windows Desktop: history threads fail to open when directive path attributes contain backslashes #23013

What version of Codex is running?

Codex Desktop reports 26.515.10909 at runtime.

Installed Windows Appx package:

OpenAI.Codex 26.513.3673.0
InstallLocation: C:\Program Files\WindowsApps\OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0

The desktop app also starts cached runtime binaries from:

%LOCALAPPDATA%\OpenAI\Codex\bin\76ac88818493fc45\codex.exe

That binary reports file/product version 0.131.0-alpha.9.

What platform / OS are you using?

Windows 11, Codex Desktop app.

What problem did you encounter?

Some existing local history threads fail to open in Codex Desktop on Windows. The data is still present on disk under:

%USERPROFILE%\.codex\sessions
%USERPROFILE%\.codex\archived_sessions
%USERPROFILE%\.codex\session_index.jsonl

The failure appears to be triggered by directive-shaped text inside JSONL messages when directive attributes named cwd, cwds, or file contain Windows absolute paths using backslash separators.

I am intentionally not including a complete raw directive example here, because the problem appears to involve directive parsing/rendering and I do not want this issue page or copied text to reproduce the same parser failure.

What did you expect to happen?

Codex Desktop should be able to open old local history threads even if message text contains Windows-style path separators inside directive attributes.

The renderer/parser should normalize or tolerate Windows absolute paths in directive attributes such as cwd, cwds, and file. A single historical message should not prevent the thread from opening.

What actually happened?

Affected history threads failed to open in Codex Desktop. The underlying JSONL files and session index remained present on disk.

Local investigation

I scanned only JSONL files under:

%USERPROFILE%\.codex\sessions
%USERPROFILE%\.codex\archived_sessions

I looked only for directive-shaped text and only for directive attributes named cwd, cwds, or file.

Initial repair run:

• JSONL files scanned: 39
• Files containing offending directive path attributes: 8
• Offending directive path attributes repaired: 370 total
  • 367 found in the initial scan
  • 3 more appeared in a live session while the repair was running
• Modified JSONL files parsed line-by-line after repair: 0 parse errors
• Full target rescan after repair: 0 remaining offending directive path attributes

Later, the same issue reappeared:

• JSONL files scanned: 39
• Files containing offending directive path attributes: 1
• Offending directive path attributes repaired: 6
• Full target rescan after repair: 0 remaining offending directive path attributes
• Full JSONL parse validation after repair: 0 error files

The repair was intentionally narrow: it only changed Windows path separators inside cwd, cwds, or file directive attribute values, converting backslash separators to forward slashes. It did not delete, truncate, slim, or otherwise rewrite conversations.

After this narrow conversion, affected threads were readable again after restarting Codex Desktop.

Why this seems like a Codex Desktop parser/renderer bug

The bad data is ordinary JSONL message text that remains parseable as JSON. The failure seems to happen later, when Codex Desktop interprets directive-shaped text. The app should not crash or refuse to open a history thread because a directive attribute contains a Windows path with backslashes.

This may be related to the broader Windows path-normalization issues tracked in:

• File paths on Windows improperly treat their UNC representation as canonical #10347
• Windows: Codex launches tools with \\?\ namespace cwd, breaking pnpm/Node tooling #13845
• Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540
• Windows Desktop: sidebar/project list lost after update; search still finds threads; projectless-thread-ids workaround restores flat chats but project grouping remains broken #19873

but this report is specifically about local history threads failing to open because directive attributes inside JSONL message text contain Windows backslash paths.

Suggested fix

Normalize or tolerate Windows paths before parsing/rendering Codex directive attributes. At minimum, directive attributes named cwd, cwds, and file should accept Windows absolute paths with backslashes and should not break the thread renderer.

A read-time compatibility repair would also help old local histories: when loading session JSONL, normalize those directive attribute path values before directive parsing/rendering.