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

Open 💬 2 comments Opened May 24, 2026 by wil70

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

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

What is the expected behavior?

The automation to run and output results in the same chat

Additional information

Fail on windows

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

#23311
#23803
#23002
#24178
#23900

Powered by Codex Action

yui-stingray · 3 months ago

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/codex main at 7d47056. The running-thread stale-path guard in codex-rs/app-server/src/request_processors/thread_processor.rs:2797-2809 still compares requested_path != active_path directly before returning cannot 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 in codex-rs/utils/path-utils/src/path_utils_tests.rs:106-113) and codex-rs/utils/absolute-path/src/lib.rs:153-170 (supported Windows device/verbatim prefix normalization). The same thread_processor.rs file already uses path_utils::paths_match_after_normalization for cwd filtering at :3491-3494, but not in the rollout-path guard above. The cwd normalization at :3877-3883 only 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-2346 verifies 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.