Windows Desktop: thread/resume rewrites rollout_path to \\?\ form, then archive fails with os error 2

Summary

On Codex Desktop for Windows, opening/resuming an existing local thread rewrites threads.rollout_path in %USERPROFILE%\.codex\state_5.sqlite from a normal drive path to a Windows extended-length path prefixed with \\?\. Archiving that thread immediately afterwards then fails with os error 2, even though the rollout JSONL exists and is readable.

Normalizing the stored path back to C:\... makes archiving succeed. Opening the same thread again triggers thread/resume, restores the \\?\C:\... form, and the failure reproduces.

Environment

• Codex Desktop: 26.814.5517.0 (Microsoft Store)
• Bundled/task CLI/app-server version recorded in the affected row: 0.148.0-alpha.15
• Platform: Windows x64
• Local task, source=vscode, thread_source=user
• State DB: %USERPROFILE%\.codex\state_5.sqlite

The Store updater reports hasUpdate=false / NoUpdates.

Reproduction

1. Start with an active local thread whose DB row has a normal rollout path:

``
C:\Users\<USER>\.codex\sessions\YYYY\MM\DD\rollout-...jsonl
``

1. Archive/unarchive can succeed while the thread is not opened.
2. Open the thread in Codex Desktop.
3. Desktop logs show:

``
maybe_resume_started
method=thread/read ... errorCode=null
method=thread/resume ... errorCode=null
maybe_resume_success
``

1. Inspect the DB row. rollout_path is now:

``
\\?\C:\Users\<USER>\.codex\sessions\YYYY\MM\DD\rollout-...jsonl
``

1. Click Archive.
2. The UI reports failure, and the log contains:

``
method=thread/archive ... errorCode=-32603
failed to archive session: thread-store internal error:
failed to archive thread: The system cannot find the file specified. (os error 2)
``

This is deterministic for the affected thread: normalize path -> archive succeeds; restore/open -> thread/resume rewrites it with \\?\; archive fails again.

Local validation

• The rollout JSONL exists at the stored location.
• Both the ordinary path and Windows extended-length path resolve/read successfully outside the archive operation.
• The parent sessions directory and archived_sessions directory exist.
• The current user has full control over the relevant directories.
• SQLite PRAGMA integrity_check returns ok.
• The JSONL parses and is not missing.
• There are no missing active rollout files for the affected rows.
• Reinstalling/updating the Desktop app did not resolve the behavior.
• This is not caused by a previous archive move: restoring the thread leaves the DB and file in the expected active state until the thread is opened/resumed.

Expected behavior

thread/resume should not persist a rollout path representation that thread/archive cannot subsequently handle. Windows path normalization should be consistent across lookup/read/resume/archive.

Suspected area

The current local archive implementation obtains the rollout path, scopes/canonicalizes it under sessions, and then calls std::fs::rename:

• codex-rs/thread-store/src/local/archive_thread.rs
• scoped_rollout_path(...)

This appears to be an inconsistency between Windows canonical/extended-length path handling during resume/reconciliation and archive.

Related issues

• #24178 — state DB contains a mixture of normal and \\?\ Windows paths
• #5290 — Windows rollout path normalization caused archive rejection (closed as fixed)
• #26012 — Desktop archive/restore rollout-path inconsistency
• #26174 — stale rollout path after unarchive
• #25769 / #25713 — active-thread archive/resume state problems

Those reports appear related, but I did not find one with this exact deterministic sequence: opening a valid active thread changes rollout_path to \\?\..., then archive fails with os error 2.