Windows Desktop: heartbeat/manual automation run cannot resume thread because C:\... and \\?\C:\... session paths are treated as different #20626

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

Codex App for Windows 26.429.2026.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows 11 x64

What issue are you seeing?

On Windows Desktop, manually triggering a heartbeat automation fails to resume the existing thread because Codex treats a normal DOS path and the equivalent \?\ namespace path as different session paths.

The automation fails with a mismatched-path error even though both paths point to the same session JSONL file.

Exact error:

cannot resume running thread 019dd96b-96f5-78d2-9a95-f4e86ba05687 with mismatched path: requested C:\Users\<user>\.codex\sessions\2026\04\29\rollout-2026-04-29T15-26-40-019dd96b-96f5-78d2-9a95-f4e86ba05687.jsonl, active \\?\C:\Users\<user>\.codex\sessions\2026\04\29\rollout-2026-04-29T15-26-40-019dd96b-96f5-78d2-9a95-f4e86ba05687.jsonl

What steps can reproduce the bug?

1. Create a heartbeat automation attached to an existing local Codex Desktop thread on Windows.
2. Let the thread/session exist on disk under .codex/sessions/.../rollout-*.jsonl.
3. Manually trigger the automation (or attempt to resume the running thread).
4. Observe that Codex compares the same session file under two equivalent path forms:
   • C:\Users\<user>\...
   • \\?\C:\Users\<user>\...
5. The automation fails instead of resuming the thread.

What is the expected behavior?

Codex should normalize equivalent Windows path forms before comparing thread/session paths, so the automation resumes the existing thread normally.

What do you see instead?

Codex refuses to resume the thread because it believes the requested path and active path are different, even though they refer to the same file.

Additional information

This looks closely related to other Windows path-normalization/path-identity bugs involving \\?\ prefixes and session/project matching, especially issue #18253.

In the failing case, the difference appears to be purely path-format identity, not missing files or a corrupted session.