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

[Smoo-G]

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
   

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

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

5. Inspect the DB row. rollout_path is now:

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

6. Click Archive.
7. 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

• Codex Desktop conversations become empty and resume fails with stale Windows path #24178 — state DB contains a mixture of normal and \\?\ Windows paths
• Archiving chat fails. MCP returns “rollout path … must be in sessions directory” #5290 — Windows rollout path normalization caused archive rejection (closed as fixed)
• Codex Desktop loses command/tool details after thread restore/archive, and archive restore path becomes inconsistent #26012 — Desktop archive/restore rollout-path inconsistency
• Codex Desktop unarchive leaves stale archived rollout path #26174 — stale rollout path after unarchive
• Codex Desktop macOS: archiving the currently viewed chat leaves right pane on archived thread and triggers session is archived #25769 / Codex Desktop Windows: archiving the active thread succeeds, then UI repeatedly resumes archived thread and freezes #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.

[github-actions]

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

• Windows: thread/archive fails with "os error 2" after thread/resume stores a \\?\ (verbatim) rollout_path — same file queued twice #39239
• [Windows] Archiving fails with os error 2 when rollout paths use the \\?\ prefix; external path normalization is ineffective #39209
• # [Windows] Unable to archive threads when rollout_path contains \\?\ prefix #39378
• [Windows] Cannot archive conversations when rollout paths use the \\?\ prefix #39150
• Windows: archiving reopened legacy tasks fails with os error 2 #39454

Powered by Codex Action