# [Windows] Unable to archive threads when `rollout_path` contains `\\?\` prefix

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

26.814.5167.0

What subscription do you have?

plus

What platform is your computer?

win11

What issue are you seeing?

[Windows] Unable to archive threads when rollout_path contains \\?\ prefix

Description

On Codex Desktop for Windows, some existing threads cannot be archived.

When I click Archive from the sidebar, Codex always shows:

Unable to archive conversation

The affected conversations are already finished and are not running any active task.

Other conversations can be archived normally, so this does not appear to be a general account or archive-permission issue.

I reproduced the problem on two separate threads.

Environment

• OS: Windows
• Product: Codex Desktop
• Codex version: latest version available to me as of August 19, 2026
• CODEX_HOME: default %USERPROFILE%\.codex

Affected threads included:

01a012d5-...-bf328746b8d8
01a013e3-...-e3cf8eb052e0

Both showed the same behavior.

Actual behavior

For an affected thread:

1. The conversation appears normally in the Codex sidebar.
2. The task has already completed.
3. Clicking ... -> Archive shows Unable to archive conversation.
4. Restarting Codex does not help.
5. Signing out and signing back in does not help.
6. Updating Codex Desktop does not help.
7. Repeated archive attempts continue to fail.

The corresponding rollout file remains under:

%USERPROFILE%\.codex\sessions\

and does not appear under:

%USERPROFILE%\.codex\archived_sessions\

Diagnostics

I inspected the affected thread in:

%USERPROFILE%\.codex\state_5.sqlite

Using:

SELECT id, archived, archived_at, rollout_path
FROM threads
WHERE id = ?;

The affected thread had:

archived     = 0
archived_at  = NULL

rollout_path =
\\?\C:\Users\<username>\.codex\sessions\2026\08\18\rollout-....jsonl

The important part appears to be the Windows verbatim-path prefix:

\\?\

The actual rollout file exists at the equivalent normal Windows path:

C:\Users\<username>\.codex\sessions\2026\08\18\rollout-....jsonl

Session integrity

I also checked whether the rollout JSONL itself was corrupted.

The affected session contained 660 JSONL lines.

When read explicitly as UTF-8, every line successfully parsed as JSON:

Total lines: 660
Parse failures: 0

The rollout file was also:

IsReadOnly: False

So the failure does not appear to be caused by malformed JSONL data or file permissions.

Workaround

I found a reproducible workaround.

First, I fully quit Codex Desktop and backed up:

%USERPROFILE%\.codex\state_5.sqlite

Then I changed only the affected thread's rollout_path from:

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

to:

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

I did not manually modify:

archived
archived_at

and I did not manually move the rollout file.

After changing only rollout_path, I restarted Codex Desktop and archived the thread directly from the sidebar without opening the conversation first.

The archive succeeded immediately.

The rollout file was then moved normally from:

.codex\sessions

to:

.codex\archived_sessions

I repeated the same procedure on a second affected thread and it also succeeded immediately.

Before / after

Before:

rollout_path = '\\\\?\\C:\\Users\\<username>\\.codex\\sessions\\...'
archived     = 0
archived_at  = None

After manually normalizing only the path:

rollout_path = 'C:\\Users\\<username>\\.codex\\sessions\\...'
archived     = 0
archived_at  = None

Then, after using Codex's normal Archive action, the thread archived successfully.

Expected behavior

Codex should treat:

\\?\C:\Users\...\file.jsonl

and:

C:\Users\...\file.jsonl

as referring to the same Windows filesystem path, or otherwise consistently normalize rollout_path before performing archive operations.

Archiving an existing completed thread should succeed regardless of whether its stored rollout path uses the Windows \\?\ verbatim-path prefix.

Suspected cause

This looks like a Windows path-normalization issue in the thread/archive flow.

A thread's rollout_path can apparently be stored in state_5.sqlite using the Windows verbatim-path form:

\\?\C:\...

while the archive logic appears to expect or compare against the normal form:

C:\...

Because changing only this field makes the archive operation succeed consistently, rollout_path normalization appears to be directly involved in the failure.

The issue may be related to opening/resuming an existing thread, although I have not yet isolated the exact operation that causes rollout_path to acquire the \\?\ prefix.

Reproduction

A possible reproduction path is:

1. Use Codex Desktop on Windows.
2. Create or reopen an existing thread.
3. Finish the task normally.
4. Inspect threads.rollout_path in .codex/state_5.sqlite.
5. If the stored path is in the form:

\\?\C:\Users\...

6. Attempt to archive the thread from the sidebar.
7. Codex displays:

Unable to archive conversation

8. Fully quit Codex.
9. Normalize only that database value to:

C:\Users\...

10. Restart Codex.
11. Archive the same thread from the sidebar.
12. Archive succeeds.

Additional notes

I initially investigated the Codex Desktop logs, but clicking Archive did not produce a useful archive-related error in the log file I was monitoring.

The problem was isolated by inspecting the session file and state_5.sqlite.

Since two independent affected threads were both fixed by changing only the \\?\ path representation, this appears to be a deterministic Codex Desktop Windows bug rather than corruption of a specific conversation.

I can provide additional database field values or sanitized diagnostics if needed.

What steps can reproduce the bug?

any session can reproduce this bug

What is the expected behavior?

No response

Additional information

No response

Start by reproducing the archive action with a thread whose threads.rollout_path in state_5.sqlite uses the Windows \?\ prefix, then trace the desktop archive flow that reads that value. Compare the failing path form with the normalized path that succeeds and verify the completed thread moves from .codex\sessions to .codex\archived_sessions without manual database edits.