[Bug] Archiving a conversation fails with "failed to archive thread: 系统找不到指定的文件。 (os error 2)" when rollout_path is stored in extended-length form

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

26.818.2441.0

What subscription do you have?

No subscription

What platform is your computer?

Windows 11

What issue are you seeing?

Archiving a conversation fails with "failed to archive session: thread-store internal error: failed to archive thread: 系统找不到指定的文件。 (os error 2)". The thread's rollout_path is stored in state_5.sqlite in Windows extended-length form (\?\D:...); the same thread archives successfully after the path is rewritten to plain form. The app rewrites the path back to the extended form whenever the thread is loaded, so the issue recurs.

What steps can reproduce the bug?

1. Use a setup where Codex data lives on a non-system drive: set CODEX_HOME=D:\<data-root>\.codex and/or have C:\Users\<user>\.codex be a junction to D:\<data-root>\.codex.
2. Create a conversation (or open an existing one) so that its rollout_path in state_5.sqlite is stored in extended-length form, e.g. \\?\D:\<data-root>\.codex\sessions\<yyyy>\<MM>\<dd>\rollout-<thread-id>.jsonl. The file exists at that path.
3. Click "Archive chat" in the sidebar, or run codex archive <thread-id>.
4. Archiving fails with failed to archive session: thread-store internal error: failed to archive thread: 系统找不到指定的文件。 (os error 2) (JSON-RPC code -32603, method thread/archive).

Verification: with the app closed, rewriting that thread's rollout_path in state_5.sqlite to the plain form (D:\<data-root>\.codex\sessions\...) makes the exact same codex archive <thread-id> command succeed and move the file into archived_sessions.

What is the expected behavior?

Archiving a conversation should succeed regardless of how the rollout path is stored. The thread-store should resolve the session file by thread id (normalizing the \\?\ extended-length prefix when needed) instead of failing on the path string representation. A failed archive should also not leave the thread in a broken "thread not found" state.

Additional information

Additional context:
Threads in this setup are persisted in state_5.sqlite with mixed rollout_path forms: extended-length (\\?\D:\...), junction form (C:\Users\<user>\.codex\...), and plain form (D:\<data-root>\.codex\...). Only the extended-length form fails to archive (os error 2), even though the file is readable/writable through that path.
The app rewrites a thread's rollout_path back to the extended form whenever it loads/hydrates the thread, so any DB-level fix gets overwritten and the bug recurs for threads that have been opened.
Regression evidence: bulk archiving of the same sessions succeeded with the previous build (26.814.x, per app-server logs); the first failing thread was created after the auto-update to 26.818.
Related observations (possibly separate issues): stale thread-writer-locks/<id>.lock files cause archive to fail with "thread already has an active writer"; archive is non-atomic (session torn down before the file move, leaving "thread not found" until restart); the projectless workspace Documents\Codex must be a real directory, a junction there causes "Projectless thread directory must be a real directory" on submit.
Workaround: with the app closed, rewrite rollout_path to plain form and remove any stale thread-writer-locks/<id>.lock, then run codex archive <thread-id>.