Codex Desktop Windows - resume fails because same session path is compared in two Windows path formats.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #23002
• #22854
• #22971
• #22403
• #21898

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. Windows running thread resume rejects same rollout path with verbatim prefix #23002 Windows: Cannot resume thread due to C:\ path vs \\?\C:\ path mismatch until Codex process is killed #22854 Codx Chat History Bug after updating #22971 VS Code Codex extension frequently fails to resume conversations with stale path on Windows #22403 * app-server thread/resume rejects equivalent symlinked rollout paths as stale #21898 _Powered by Codex Action_

even though 2 days ago
etraut-openai
said
"We've issued a hotfix to address this. Please update to the latest version."

it is still happening.

v26.513 did not fix the issue.

I am seeing the same bug on Windows with Codex Desktop after the reported hotfix.

Environment observed locally:

• Codex Desktop: 26.513.40821
• Session log / app-server CLI version: 0.131.0-alpha.9
• Platform: Windows, local Codex data under %USERPROFILE%\.codex
• Affected scenario: heartbeat automations / reopening automation target threads

Representative error:

cannot resume running thread <thread-id> with stale path:
requested `C:\Users\<user>\.codex\sessions\2026\05\20\rollout-2026-05-20T10-15-46-<thread-id>.jsonl`,
active `\\?\C:\Users\<user>\.codex\sessions\2026\05\20\rollout-2026-05-20T10-15-46-<thread-id>.jsonl`

A few details that may help narrow it down:

1. Restarting Codex Desktop did not clear the problem.
2. The affected rollout-*.jsonl files existed and were readable; this was not a missing rollout file.
3. The corresponding rows in %USERPROFILE%\.codex\state_5.sqlite had threads.rollout_path stored in normal Windows form:

C:\Users\<user>\.codex\sessions\...\rollout-...jsonl

while the runtime active path in the error used the extended Windows prefix:

\\?\C:\Users\<user>\.codex\sessions\...\rollout-...jsonl

1. Manually backing up state_5.sqlite and updating the affected threads.rollout_path values to the \\?\C:\... form made those paths match the active path and appears to mitigate the issue locally.
2. This reproduced even after the automations were paused, so the immediate trigger was not only the heartbeat interval. The stale-path check can still fail when trying to resume/reopen an existing target thread whose persisted rollout path and active rollout path are spelled differently.

Expected behavior remains that Codex should compare canonical file identity / normalized Windows paths instead of doing a literal string comparison between C:\... and \\?\C:\....

I see the same bug, session paths now have that weird \\?\ in front of them

Thanks for the report. This was a valid bug: Codex compared the two Windows path representations without normalizing them first.

The issue has now been fixed by #25509. The fix is included in Codex CLI 0.137.0-alpha.4 and later. Please update Codex Desktop to a version containing that CLI release.