Windows: running thread resume rejects same rollout path when one side uses \\?\ prefix
Summary
On Windows, creating or resuming work against an already-running thread can fail with a stale-path error even when the requested rollout file and the active rollout file are the same file.
Observed error:
cannot resume running thread 019e6296-8510-7243-8d00-c899d5139d9e with stale path: requested `C:\Users\Lenovo\.codex\sessions\2026\05\26\rollout-2026-05-26T12-41-37-019e6296-8510-7243-8d00-c899d5139d9e.jsonl`, active `\\?\C:\Users\Lenovo\.codex\sessions\2026\05\26\rollout-2026-05-26T12-41-37-019e6296-8510-7243-8d00-c899d5139d9e.jsonl`The two paths refer to the same file. The only difference is Windows' verbatim / extended-length path prefix (\\?\).
Impact
This can leave Codex Desktop unable to create tasks or resume a running thread. It can happen repeatedly if persisted thread metadata and the active running-thread path use different Windows path representations.
Likely cause
thread_processor.rs compares params.path and the active running-thread rollout path with direct PathBuf equality before rejoining a running thread. On Windows, direct equality treats C:\... and \\?\C:\... as different even when they identify the same file.
Expected behavior
The stale-path check should compare normalized paths, so Windows verbatim and non-verbatim equivalents are accepted while genuinely stale or different rollout files are still rejected.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I have a small reference patch prepared here:
The patch changes the running-thread resume stale-path guard from direct
PathBufequality topath_utils::paths_match_after_normalization, and adds a Windows regression test forC:\...vs\\?\C:\...rollout path equivalents.Validation performed locally:
git diff --checkcargo +stable fmt --checkThe focused Rust test was also attempted, but dependency fetch/build did not complete in the local environment within the available time.