Windows: Cannot resume thread due to C:\ path vs \\?\C:\ path mismatch until Codex process is killed

What version of the Codex App are you using (From “About Codex” dialog)?

26.506.3741.0

What subscription do you have?

Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

I couldn’t resume an existing thread in the Codex desktop app on Windows.

The app showed this error:

cannot resume running thread <SESSION_ID> with stale path: requested `C:\Users\<USER>\.codex\sessions\2026\05\15\rollout-2026-05-15T13-41-32-<SESSION_ID>.jsonl`, active `\\?\C:\Users\<USER>\.codex\sessions\2026\05\15\rollout-2026-05-15T13-41-32-<SESSION_ID>.jsonl`

The session file existed, but Codex failed to resume it because the requested path used:

``C:\Users\<USER>\... ``

while the active path used:

``\\?\C:\Users\<USER>\...``

Trying to resume again did not fix it. What fixed it was opening Task Manager, ending the Codex process manually, reopening the Codex app, and then opening the thread again.

What steps can reproduce the bug?

This happened with an existing Codex desktop app session on Windows.

Steps:

1. Have an existing Codex thread/session saved under:

C:\Users\<USER>\.codex\sessions\...

1. Try to resume/open that thread from the Codex desktop app.

1. Codex fails with a stale path error where one path uses:

C:\Users\<USER>\...

and the other uses:

\\?\C:\Users\<USER>\...

1. Trying to reopen/resume the thread again still fails.

1. Open Windows Task Manager.

1. End the Codex process manually.

1. Reopen the Codex app.

1. The thread becomes resumable again.

I don’t have a minimal code reproduction, but it seems related to stale session state being kept by the Codex process.

What is the expected behavior?

Codex should handle both of these Windows path formats as the same path:

C:\Users\<USER>\...

and:

\\?\C:\Users\<USER>\...

Resuming a thread should not fail just because the same session file is represented with a different valid Windows path format.

Also, closing the Codex app should clear or recover from stale session state without requiring the user to manually end the Codex process from Task Manager.

Additional information

This happened in the Codex desktop app, not the VS Code extension.

I saw a similar Windows path mismatch reported for the VS Code extension, but I’m opening this separately because this happened in the desktop app and the workaround was different where I had to manually end the Codex process from Task Manager.

Workaround that fixed it:

1. Open Task Manager.
2. End the Codex process manually.
3. Reopen the Codex app.
4. Resume/open the thread again.

Possible cause: Codex may be comparing raw Windows path strings instead of normalizing them first, and a background process may be keeping stale session state alive.