[Windows] Restored threads cannot be archived after restart; rollout_path changes from C:\... to \\?\C:\...

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

26.819.11345

What subscription do you have?

plus

What platform is your computer?

windows10

What issue are you seeing?

On Codex Desktop for Windows, threads created during the current application session can be archived normally, but threads that remain unarchived across an application restart can no longer be archived.

The behavior I consistently observe is:

• A newly created thread has a normal rollout_path such as:

C:\Users\<USER>\.codex\sessions\...\<thread-id>.jsonl

• If I close and restart Codex while that thread is still unarchived, the restored thread's rollout_path changes to:

\\?\C:\Users\<USER>\.codex\sessions\...\<thread-id>.jsonl

• After that, attempting to archive the restored thread does not complete successfully. The thread remains unarchived and its JSONL file remains under .codex\sessions instead of being moved to .codex\archived_sessions.

• A new thread created after the restart still uses a normal C:\... rollout_path and can be archived successfully.

There is no visible error message in the UI when the archive operation fails.

I also observed thread/archive requests being issued for affected threads, but the local database still shows archived=0 and the corresponding JSONL file is not moved.

One example of an affected thread is:
01a01dab-b566-79f0-a9ac-914cc5042748

This appears to be specifically related to restoring threads after restarting Codex on Windows, rather than the conversation content, account, workspace, or filesystem permissions.

What steps can reproduce the bug?

1. Start Codex Desktop on Windows.

1. Create a new thread (Thread A) and leave it unarchived.

At this point, its rollout_path uses a normal Windows path, for example:
C:\Users\<USER>\.codex\sessions\...\<thread-id>.jsonl

1. Completely close Codex Desktop and start it again.

1. After restart, inspect Thread A.

Its rollout_path has changed to:
\\?\C:\Users\<USER>\.codex\sessions\...\<thread-id>.jsonl

1. Try to archive Thread A.

The archive operation fails: the thread remains unarchived and its JSONL file remains under .codex\sessions.

1. Without restarting Codex again, create a new thread (Thread B).

1. Thread B uses a normal rollout_path:

C:\Users\<USER>\.codex\sessions\...\<thread-id>.jsonl

1. Archive Thread B.

Thread B archives successfully and its JSONL file is moved to .codex\archived_sessions.

This is reproducible on my system: threads that have been restored after an application restart cannot be archived, while threads created during the current Codex session can be archived normally.

What is the expected behavior?

Threads should remain fully functional and archivable after restarting Codex Desktop.

Restarting the application should not change a thread's effective session path in a way that affects archive behavior. Whether the rollout_path is represented as:

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

or:

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

Codex should treat both as the same Windows path.

Archiving a restored thread should succeed normally: the thread should be marked as archived and its session file should be moved from .codex\sessions to .codex\archived_sessions.

Additional information

I performed a controlled A/B test and inspected the local Codex state.

Thread A:
01a01de4-3dfa-7d20-8c0b-f662acea8c52

• Created before restarting Codex.
• Before restart, rollout_path was a normal Windows path:

C:\Users\<USER>\.codex\sessions\...\01a01de4-3dfa-7d20-8c0b-f662acea8c52.jsonl

• After restarting Codex, without archiving or modifying the thread, rollout_path became:

\\?\C:\Users\<USER>\.codex\sessions\...\01a01de4-3dfa-7d20-8c0b-f662acea8c52.jsonl

Thread B:
01a01de5-88bf-7e31-858c-9f496e83896e

• Created after the restart.
• rollout_path remained a normal C:\... path.
• Thread B archived successfully.
• Its JSONL file was moved from .codex\sessions to .codex\archived_sessions.

I also inspected state_5.sqlite. At the time of investigation:

• Total threads: 624
• Archived threads: 519
• Threads with a \\?\-prefixed rollout_path and archived=0: 35
• Threads with a \\?\-prefixed rollout_path and archived=1: 0
• Normal rollout_path and archived=1: 519

This shows a very strong correlation between a \\?\-prefixed rollout_path and archive failure.

The database itself appears healthy:

• PRAGMA quick_check passes.
• PRAGMA foreign_key_check reports no errors.

I also completely deleted C:\Users\<USER>\.codex, restarted Codex, logged in again, created new threads, restarted the application, and reproduced the same behavior. Therefore, simply clearing the local .codex state does not resolve the issue.

Another observation: creating a branch from an affected thread creates a new thread with a normal C:\... rollout_path, and the new thread can be archived normally.

This may be related to #26059, which reports a similar Windows path normalization mismatch between C:\... and \\?\C:\..., although that issue concerns resuming threads while this report concerns archiving restored threads.

The \\?\ prefix itself is valid Windows syntax. My suspicion is that the bug is caused by inconsistent path normalization or comparison between the thread restoration code path and the archive code path.