[Windows] Archiving a local task fails when threads.rollout_path contains a \\?\ prefix

Summary

Archiving certain local Codex tasks on Windows fails with
"failed to archive conversation."

After the failure, the task remains in the sidebar with a red
exclamation mark. Its history may still be visible, but opening it
also displays a "thread not found" error, leaving it in a partially
archived/deleted state.

Environment

• OS: Windows [edition/version/build]
• Codex desktop package: 26.814.41407
• CODEX_HOME: default %USERPROFILE%\.codex
• Filesystem: [NTFS]
• .codex is a normal directory, not a junction or symbolic link

Steps observed

1. Create or use a local Codex task.
2. Send messages and later reopen/resume the task.
3. Attempt to archive it from the sidebar.
4. Codex reports "failed to archive conversation."
5. The task remains in the sidebar with a red exclamation mark.
6. Opening it shows its history but also reports that the thread was

not found.

Expected result

The task should be moved to the archived-task list, its transcript
should be moved to archived_sessions, and the sidebar should no
longer show an error.

Actual result

Archiving fails and leaves the task in an inconsistent state.

Local database finding

The affected task's threads.rollout_path begins with the Windows
extended-path prefix:

\\?\C:\Users\<redacted>\.codex\sessions\...\rollout-....jsonl

The first four bytes reported by SQLite are:

5C5C3F5C

The transcript file exists at the corresponding ordinary path.

There are no SQLite triggers modifying rollout_path.

Workaround and causality

With Codex fully closed, changing only threads.rollout_path from:

\\?\C:\Users\<redacted>\.codex\sessions\...\file.jsonl

to:

C:\Users\<redacted>\.codex\sessions\...\file.jsonl

allows the task to be archived successfully.

Opening/resuming or updating a repaired task may cause Codex to write
the \\?\ prefix back into threads.rollout_path.

Cross-computer evidence

The same diagnostic found active tasks with \\?\ rollout paths on a
second Windows computer with no unexpected CODEX_HOME, directory-link,
or path settings.

This makes a machine-specific configuration problem unlikely.