[Windows][Desktop] thread/archive fails when rollout_path uses the \\?\ prefix and list activity reintroduces it

Summary

On Codex Desktop for Windows, archiving some local threads fails when the persisted threads.rollout_path uses the Windows extended-length path form (for example, \\?\C:\...). Restarting the app is not a durable workaround because later thread-list activity can persist that form again.

This report is based on a local state audit and a controlled canary archive. It does not include session contents, raw logs, user paths, or thread IDs.

Environment

• OS: Windows x64
• Codex Desktop build observed in the failure logs: 26.818.22352
• Local state database: state_5.sqlite
• Session storage: default Codex session and archived-session directories

Observed behavior

Five failed thread/archive operations stopped after the thread listener was cleared during thread-state teardown. Every affected row had a rollout_path beginning with the Windows verbatim-path prefix.

A controlled test then produced the following result:

1. Validate that each target path resolves to an existing session file under the Codex session root.
2. In a transaction, normalize 25 affected active rollout_path values from the verbatim drive form to the normal drive form.
3. Archive one canary thread through the normal Desktop/App Server API.
4. The canary archive succeeds: the file is moved to the archived-session directory and the database archived state is consistent.
5. After subsequent normal list activity, 9 active rows are persisted again with the verbatim-path prefix.

The database passed PRAGMA integrity_check. The wider audit found no missing session files for database rows, no archive-flag/location mismatches, no filename/thread-ID mismatches, and no duplicate canonical rollout paths.

Expected behavior

Windows paths that identify the same file should be treated as equivalent throughout list, resume, persistence, archive, and unarchive operations. Normal list activity should not write a path representation that a later archive operation cannot consume.

Likely cause

The leading observed precondition and likely proximate cause is inconsistent Windows path canonicalization across App Server stages:

• a list/resume/rollout-discovery path persists the verbatim drive form;
• the archive path handling later expects or compares against the normal drive form.

The exact writer function and exact failing archive-stage operation remain inferred; this report does not claim a source-level trace.

Suggested fix

1. Establish a single Windows path representation at the threads.rollout_path persistence boundary.
2. Normalize both operands before path comparison or strip_prefix-style operations in archive handling.
3. Handle verbatim drive paths and verbatim UNC paths separately; do not remove \\?\ with an unconditional string replacement.
4. Backfill existing rows only after verifying that the normalized path remains inside the Codex session root, exists, and does not collide.
5. Add Windows regression coverage for:

• normal drive paths;
• verbatim drive paths;
• verbatim UNC paths;
• list/resume idempotence;
• archive/unarchive round trips;
• active-thread teardown during archive.

Related issues

• #19128 documents Desktop rewriting threads.cwd to the \\?\ form.
• #23803 documents resume failure when two path strings differ only by the verbatim prefix.

This appears to be the corresponding threads.rollout_path / archive failure mode rather than only a workspace-grouping or resume symptom.

Privacy

No usernames, absolute user paths, project names, thread/session IDs, session contents, database files, or raw log attachments are included. Sanitized excerpts can be provided if maintainers need a narrower trace.