Repository navigation
Codex Desktop automation heartbeat fails on Windows due to stale session path mismatch between C:\... and \\?\C:\... #24338
Description
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:
- On Windows, create a Codex Desktop heartbeat automation attached to an existing chat/thread.
- Let it run repeatedly over time, or restart/reopen Codex Desktop between runs.
- At some point the automation tries to resume the same thread.
- 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
- requested path is
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:
- On Windows, create a Codex Desktop heartbeat automation attached to an existing chat/thread.
- Let it run repeatedly over time, or restart/reopen Codex Desktop between runs.
- At some point the automation tries to resume the same thread.
- 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
- requested path is
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
Activity
github-actions commentedon May 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
yui-stingray commentedon May 24, 2026
This still appears related to #23311 / #23803 / #23002 / #24178 / #23900, but this report adds a useful current data point: it says the
C:\...vs\\?\C:\...rollout-path mismatch still happens on Windows 10 Pro with the latest app as of 2026-05-24.I checked
openai/codexmainat7d47056. The running-thread stale-path guard incodex-rs/app-server/src/request_processors/thread_processor.rs:2797-2809still comparesrequested_path != active_pathdirectly before returningcannot resume running thread ... with stale path.There are already normalization utilities that look relevant, for example
codex-rs/utils/path-utils/src/lib.rs:13-29(paths_match_after_normalization, with a Windows verbatim-path test incodex-rs/utils/path-utils/src/path_utils_tests.rs:106-113) andcodex-rs/utils/absolute-path/src/lib.rs:153-170(supported Windows device/verbatim prefix normalization). The samethread_processor.rsfile already usespath_utils::paths_match_after_normalizationfor cwd filtering at:3491-3494, but not in the rollout-path guard above. Thecwdnormalization at:3877-3883only applies while materializing stored thread metadata and does not affect this rollout-path equality check.The existing regression test
codex-rs/app-server/tests/suite/v2/thread_resume.rs:2213-2346verifies that truly mismatched rollout paths are rejected, but I do not see coverage for equivalent Windows spellings of the same rollout path (C:\...vs\\?\C:\...). That makes this look like either an incomplete fix or a regression of the earlier Windows resume-path issue, rather than a fully resolved duplicate.