Codex Desktop automation heartbeat fails on Windows due to stale session path mismatch between C:\... and \\?\C:\...

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

latest as of 5/24/2026

What subscription do you have?

Pro

What platform is your computer?

windows 10 pro

What issue are you seeing?

Could not start automation
cannot resume running thread 019e0f51-519b-7362-8ae3-5ae0b6662195 with stale path: requested `C:\Users\Wilhelm\.codex\sessions\2026\05\09\rollout-2026-05-09T17-37-28-019e0f51-519b-7362-8ae3-5ae0b6662195.jsonl`, active `\\?\C:\Users\Wilhelm\.codex\sessions\2026\05\09\rollout-2026-05-09T17-37-28-019e0f51-519b-7362-8ae3-5ae0b6662195.jsonl`

Title:
Codex Desktop automation heartbeat fails on Windows due to stale session path mismatch between C:\... and \\?\C:\...

Product:
Codex Desktop app on Windows

Issue:
Recurring Codex automations that are configured as heartbeat/thread-resume automations frequently fail to start with this error:

"Could not start automation
cannot resume running thread 019e0f51-519b-7362-8ae3-5ae0b6662195 with stale path: requested C:\Users\Wilhelm\.codex\sessions\2026\05\09\rollout-2026-05-09T17-37-28-019e0f51-519b-7362-8ae3-5ae0b6662195.jsonl, active \\?\C:\Users\Wilhelm\.codex\sessions\2026\05\09\rollout-2026-05-09T17-37-28-019e0f51-519b-7362-8ae3-5ae0b6662195.jsonl"

The two paths point to the same file. One is the normal Windows path and the other is the extended-length Windows path. Codex appears to compare the raw strings and treats them as different active session files, then refuses to resume the automation.

Steps to reproduce:

1. On Windows, create a Codex Desktop heartbeat automation attached to an existing chat/thread.
2. Let it run repeatedly over time, or restart/reopen Codex Desktop between runs.
3. At some point the automation tries to resume the same thread.
4. Codex fails with "cannot resume running thread with stale path" where:

• requested path is C:\Users\...\rollout-....jsonl
• active path is \\?\C:\Users\...\rollout-....jsonl

Expected behavior:
Codex should canonicalize/normalize Windows paths before comparing them, or compare file identity. C:\Users\...\file.jsonl and \\?\C:\Users\...\file.jsonl should be treated as the same session file.

Actual behavior:
The automation fails to start, even though both paths reference the same session JSONL file.

Impact:
This breaks recurring heartbeat automations every day or every few hours. The user has to manually recreate or convert automations repeatedly. It makes long-running Codex workflows unreliable on Windows.

Workaround:
Converting the automation from heartbeat/thread-resume mode to cron/workspace mode avoids the broken resume path, but this loses the intended behavior of continuing an existing chat thread.

Suggested fix:
Normalize Windows paths before stale-session comparison. For example:

• canonicalize both paths with the same Windows path API
• strip or consistently apply the \\?\ prefix before comparing
• compare resolved file identity rather than raw strings
• ensure stored active session paths and requested resume paths use the same canonical representation

This looks like a Windows path canonicalization bug in Codex Desktop automation resume logic, not a user project issue.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019e5a45-5503-78a0-89f2-26c3e9227a96

Steps to reproduce:

1. On Windows, create a Codex Desktop heartbeat automation attached to an existing chat/thread.
2. Let it run repeatedly over time, or restart/reopen Codex Desktop between runs.
3. At some point the automation tries to resume the same thread.
4. Codex fails with "cannot resume running thread with stale path" where:

• requested path is C:\Users\...\rollout-....jsonl
• active path is \\?\C:\Users\...\rollout-....jsonl

What is the expected behavior?

The automation to run and output results in the same chat

Expected behavior:
Codex should canonicalize/normalize Windows paths before comparing them, or compare file identity. C:\Users\...\file.jsonl and \\?\C:\Users\...\file.jsonl should be treated as the same session file.

Additional information

Fail on windows