[Windows] Automation resume fails on path canonicalization mismatch (C:\... vs \\?\C:\...) #20882

Activity

1. Redas17

   added

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

   on May 3, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   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

   on May 3, 2026
3. github-actions commented on May 3, 2026

   

   github-actionsbot

   on May 3, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex App automation/heartbeat repeatedly fails to resume a running thread on Windows because the same session JSONL path is compared with and without the extended path prefix. #20517
   • Windows Desktop: heartbeat/manual automation run cannot resume thread because C:\... and \\?\C:\... session paths are treated as different #20626

   Powered by Codex Action
4. etraut-openai

   added

   automations

   on May 3, 2026
5. seasonmsg commented on May 16, 2026

   

   seasonmsg

   on May 16, 2026

   More actions

   I hit the same Windows path canonicalization bug in Codex Desktop.

   Environment:

   • Windows
   • Codex Desktop installed package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
   • codex.exe version observed locally: 0.131.0.0
   • Workspace: E:\Codex

   Error:
   cannot resume running thread 019e2f67-cded-7ec1-b44c-909bf4ea40de with stale path:
   requested C:\Users\Administrator\.codex\sessions\2026\05\16\rollout-2026-05-16T14-09-52-019e2f67-cded-7ec1-b44c-909bf4ea40de.jsonl,
   active \\?\C:\Users\Administrator\.codex\sessions\2026\05\16\rollout-2026-05-16T14-09-52-019e2f67-cded-7ec1-b44c-909bf4ea40de.jsonl

   Verified:

   • Both paths point to the same file.
   • File size: 2,741,579 bytes.
   • SHA256: 36e90723532f4239dc5f183b9c51ec65f5d2e98252623879ee4931dc420f77da
   • The rollout JSONL contains final_answer and task_complete.
   • state_5.sqlite stores the normal C:\ path.
   • logs_2.sqlite shows the active resume path as \?\C:...
   • The failure matches the running-thread resume check in thread_processor.rs where requested_path and active_path are compared literally.

   Impact:
   The conversation appears in the sidebar but cannot be reopened from Codex Desktop.
6. m13v commented on May 16, 2026

   

   m13v

   on May 16, 2026

   More actions

   the \?\ vs C:\ mismatch is the classic Windows extended-length path bug. once a path passes through any Win32 canonicalization (GetFinalPathNameByHandleW, std::fs::canonicalize in Rust), it returns as \?\C:... while user-typed paths stay C:... string compare treats them as different files even though they resolve to the same handle. fix is normalizing both sides before compare, not at persist time. dunce::canonicalize strips the verbatim prefix when it's safe. hits every desktop automation framework with persistent session state eventually because the file gets touched at both layers.
7. grantusmaximus commented on May 19, 2026

   

   grantusmaximus

   on May 19, 2026

   More actions

   I’m hitting this repeatedly on Windows Codex Desktop OpenAI.Codex_26.513.4821.0.

   All heartbeat automations can fail with the same stale-path mismatch:

   • requested: C:\...\codex\sessions\...\rollout-....jsonl
   • active: \\?\C:\...\codex\sessions\...\rollout-....jsonl

   I tried several workarounds:

   • closing and reopening Codex;
   • recreating fresh target heartbeat chats;
   • rebinding the automations to the fresh thread IDs;
   • manually normalizing threads.rollout_path in state_5.sqlite to \\?\C:\....

   Recreating/rebinding the target chats appeared to work briefly, but the issue returned. Manual DB normalization also briefly verifies as correct, but Codex later rewrites threads.rollout_path back to plain C:\..., then the automation launcher can fail because the active running thread is tracked with \\?\C:\....

   I had to pause all heartbeat automations because the error toast repeats constantly. This looks like Windows path canonicalization needs to happen before the stale-path comparison, and the current local workarounds are not durable.
8. rkoivunen-sw commented on May 25, 2026

   

   rkoivunen-sw

   on May 25, 2026

   More actions

   I am seeing the same Windows path-canonicalization bug on a newer Codex Desktop build.

   Version: OpenAI.Codex 26.519.5221.0
   OS: Windows 11
   

   Observed repeated error shape:

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

   Extra proof from local logs/binary inspection:

   AppServerConnection routed method=thread/resume from originWebcontentsId=1 and returned errorCode=-32600
   electron-message-handler reported Request failed method=thread/resume
   resources\codex.exe contains "cannot resume running thread" and "stale path"
   resources\app.asar  does not contain those strings
   

   So this still appears to be the local app-server/backend comparing equivalent Windows paths literally. C:\... and \\?\C:\... should compare equal after Windows path normalization/canonicalization.