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

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

• #20517
• #20626

Powered by Codex Action

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.

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.

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.

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.

This is a path-identity bug, not a missing-file bug — C:\Users\... and \\?\C:\Users\... are the same file, but the resume path comparison is doing a string equality check on the persisted form instead of canonicalizing both sides first. The \\?\ extended-length prefix gets written by one code path (usually the one that opened the file with CreateFileW extended syntax) and the plain form by another, so the same rollout is stored under two textual identities.

The durable fix is to canonicalize Windows paths (resolve the \\?\ prefix, normalize drive-letter casing, resolve symlinks) before both persisting and comparing. But for anyone blocked right now, the useful diagnostic is to confirm the two forms actually point to the same inode/file on disk — if they do, the rollout is fine and only the comparison is broken.

Full disclosure: I maintain codex-rescue (https://github.com/shleder/codex-rescue). codex-rescue workspace --latest verifies rollout path portability across POSIX / Windows / WSL and specifically detects C:\ vs \\?\C:\ identity divergence read-only, so you can confirm your automation's "mismatched path" is a form mismatch (recoverable) rather than a genuinely different file. Alpha7 hardened the Windows extended-path normalization for exactly this class of bug.