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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   automations

   on May 18, 2026
2. github-actions commented on May 18, 2026

   

   github-actionsbot

   on May 18, 2026 – with GitHub Actions

   Contributor

   More actions

   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
3. ysc0224 commented on May 18, 2026

   

   ysc0224

   on May 18, 2026

   Author

   More actions

   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.
4. jackyshan82 commented on May 19, 2026

   

   jackyshan82

   on May 19, 2026

   More actions

   v26.513 did not fix the issue.
5. Delta-Water commented on May 20, 2026

   

   Delta-Water

   on May 20, 2026 – with ChatGPT Codex Connector

   More actions

   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
   

   4. 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.
   5. 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:\....
6. JohnAlcatraz commented on May 20, 2026

   

   JohnAlcatraz

   on May 20, 2026

   Last edited by JohnAlcatraz

   More actions

   I see the same bug, session paths now have that weird \?\ in front of them
7. etraut-openai commented on Jun 5, 2026

   

   etraut-openai

   on Jun 5, 2026

   Contributor

   More actions

   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.
8. etraut-openai

   closed this as completedon Jun 5, 2026