Windows: thread/archive fails with "os error 2" after thread/resume stores a \\?\ (verbatim) rollout_path — same file queued twice

Summary

On Windows, once a thread has been resumed, archiving it fails with:

failed to archive session: thread-store internal error: failed to archive thread: The system cannot find the file specified. (os error 2)

The rollout file exists and is readable. Root cause is a path-equality mismatch in archive_thread_with_paths that causes the same rollout file to be renamed twice.

Environment

Codex desktop 26.814.5167.0 (release 26.814.41407), bundled CLI 0.148.0-alpha.15
Windows 11 (build 26200)

Repro

Open (resume) any existing thread in the desktop app.
threads.rollout_path in state_5.sqlite is now stored as \\?\C:\Users\<user>\.codex\sessions\...\rollout-...jsonl (verbatim prefix — looks like std::fs::canonicalize output). Threads that have not been opened keep the plain C:\Users\<user>\.codex\sessions\...\rollout-...jsonl form.
Archive that thread → error above. The file is still in sessions/ afterward.
Workaround that confirms the diagnosis: strip the \\?\ prefix from that row's rollout_path, then archive without re-opening → succeeds. Re-opening the thread re-introduces the prefix and the failure.

Analysis (`codex-rs/thread-store/src/local/archive_thread.rs`)

In archive_thread_with_paths:

rollout_paths comes from owned_rollout_paths_from_index(&reference_index, ...) — a filesystem scan → plain C:\... paths.
selected_rollout_path comes from thread_rollout_resolver::resolve_current → the SQLite row → \\?\C:\....
if !rollout_paths.contains(&selected_rollout_path) { rollout_paths.push(selected_rollout_path) } compares PathBufs byte-wise, so the verbatim and non-verbatim forms of the same file are treated as different and both are queued.
Each is then passed through scoped_rollout_path (helpers.rs), which canonicalizes both to the identical source and computes the identical destination.
First std::fs::rename succeeds; the second fails with NotFound because the source was just moved. restore_rollout_moves then rolls the first move back — hence the file "still exists" and the misleading error.

Suggested fix (either/both)

Dedup rollout_moves after canonicalization (compare canonical source paths, or dedup by rollout id/filename) rather than contains on mixed-form paths beforehand.
Don't persist verbatim (\\?\) paths on resume; store the same form the scanner produces (e.g. dunce::canonicalize, or strip the verbatim prefix on Windows).

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

[Windows] Archiving fails with os error 2 when rollout paths use the \\?\ prefix; external path normalization is ineffective #39209
[Windows] Cannot archive conversations when rollout paths use the \\?\ prefix #39150
[Windows] Local thread archiving fails with thread-store os error 2 #39130

Powered by Codex Action

Independent reproduction on Windows with Codex Desktop 26.814.5167.0.

Read-only local inspection found:

Eight affected active thread records use \\?\C:\...\-prefixed rollout_path values.
All eight referenced rollout JSONL files exist and are readable; none are missing.
Conversations using plain C:\...\ rollout paths archived successfully during the same app run.
For affected conversations, the UI removes the conversation optimistically and then restores it when the archive operation fails.

This independently corroborates the path-normalization/double-move diagnosis. No usernames, private paths, conversation IDs, titles, contents, or raw logs are included, and no local state was modified during diagnosis.

Independent confirmation from another Windows installation, including a successful two-thread repair that matches this diagnosis.

Environment

Codex Desktop package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
Windows 11 Pro 10.0.26200 (build 26200)
Local Codex root: C:\Users\rikad\.codex
The affected thread metadata records cli_version = 0.147.0-alpha.6.5 from creation.

Affected threads

019fe60c-e441-7333-aabb-f7e7bd6f8817
- \\?\C:\Users\rikad\.codex\sessions\2026\08\09\rollout-2026-08-09T11-23-52-019fe60c-e441-7333-aabb-f7e7bd6f8817.jsonl
019feae1-be46-7213-bd62-9823a5f84444
- \\?\C:\Users\rikad\.codex\sessions\2026\08\10\rollout-2026-08-10T09-54-50-019feae1-be46-7213-bd62-9823a5f84444.jsonl

For both threads, the rollout file existed and C:\Users\rikad\.codex\archived_sessions existed, but thread/archive returned:

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

Before the local repair, the database distribution was:

34 unarchived rows with the \\?\ prefix
587 unarchived rows without it
0 archived rows with the prefix
343 archived rows without it

Confirmed workaround

For only the two IDs above, I removed the leading \\?\ from state_5.sqlite.threads.rollout_path while leaving the actual files untouched, then immediately called the normal thread/archive operation without reopening either thread.

Both archive calls then succeeded. Each row became archived=1, each rollout moved into archived_sessions, the destination files existed, and both IDs disappeared from the normal thread list.

This independently confirms that the stored verbatim path form is the trigger and that normalizing it before archive/deduplication resolves the failure. We can provide the complete Desktop log and additional affected rows if useful.

Confirmed independently on Windows with the same failure mode.

Environment:

Codex Desktop MSIX: 26.814.5167.0
Windows 11 Home x64: 10.0.26200
Local project thread

Observed repeatedly from the UI and native archive path:

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)

Read-only local verification of the affected thread shows:

threads.rollout_path begins with the Windows verbatim prefix \\?\C:\....
The referenced rollout JSONL exists and is readable.
The thread remains archived = 0 after every attempt.
Restarting Codex does not resolve it.
Other threads archived successfully during the same period, so the archive directory and general filesystem permissions are working.

This matches the duplicate-move/path-normalization analysis in this issue very closely. No raw logs, private paths, credentials, thread IDs, or conversation content are included here.

Confirmed independently on Windows with the same path-form mismatch.

Environment:

Codex Desktop package: 26.814.5167.0
Bundled CLI recorded in the affected session: 0.148.0-alpha.15
Windows: 10.0.26200
Local Codex thread, status notLoaded

Observed behavior:

Archiving from Codex fails consistently with:

failed to archive session: thread-store internal error:
failed to archive thread: 系统找不到指定的文件。 (os error 2)

Read-only verification:

The referenced rollout JSONL exists and is readable.
Its session_meta.session_id matches the cataloged thread.
archived_sessions exists.
The affected state_5.sqlite.threads.rollout_path begins with \\?\C:\....
Other active threads use plain C:\... paths, and recent successfully archived rows also use plain paths.

No project files, conversation content, usernames, local project paths, or thread IDs are included here. This reproduction is consistent with the double-move/path-deduplication analysis in this issue.

Another independent two-thread confirmation on Windows, with a controlled repair that matches the double-move/path-normalization diagnosis.

Environment

Codex Desktop package: 26.814.5167.0
Windows 11 x64: 10.0.26200
Local Codex threads; both affected rows recorded cli_version = 0.148.0-alpha.9

Evidence before repair

For two separate completed threads on the same installation:

thread/archive consistently failed with failed to archive thread: The system cannot find the file specified. (os error 2).
Both threads were notLoaded and had no spawn-edge dependency.
Both referenced rollout JSONL files existed and were readable.
threads.rollout_path used the \\?\C:\... form and archived = 0.
codex doctor reported the state DB integrity as ok, exact rollout-file/DB-row parity, and zero stale rows, archive mismatches, duplicate paths, duplicate thread IDs, malformed filenames, or scan errors.

Controlled repair

For each thread, I first made a consistent SQLite online backup, then changed only that row's rollout_path from \\?\C:\... to C:\..., leaving the rollout file untouched. I immediately called the normal thread/archive operation without reopening the thread.

Both archive operations then succeeded. Each rollout was moved by Codex into archived_sessions, each row became archived, and the rollout digest was unchanged across the move. A post-repair codex doctor check still reported exact filesystem/DB parity and zero archive mismatches or stale rows.

As a read-only blast-radius check, 73 of 228 current thread rows on this installation still used the verbatim prefix at the time of inspection. This does not claim that all 73 have been tested or will fail, but it suggests the persisted path form is not rare.

No usernames, absolute user paths, thread IDs, titles, project names, conversation content, rollout contents, raw logs, database files, credentials, or digests are included here. This further corroborates that the files are not missing and that normalizing/deduplicating equivalent Windows paths before scheduling rollout moves should address the failure.

Additional independent reproduction on Codex Desktop for Windows (MSIX package 26.814.5167.0, ARM64): archiving fails for every tested local task, not just one conversation.

Observed error from the Desktop log for each thread/archive request:

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

Read-only checks confirm the affected rollout JSONL files still exist under the dated ~/.codex/sessions/YYYY/MM/DD/ tree, and ~/.codex/archived_sessions exists and is writable. Restarting Windows and using Windows App Repair did not change the behavior.

This is consistent with the mixed normal/verbatim (\\?\\) Windows rollout-path handling described in this issue. No task content, credentials, or local usernames are included here.

Confirmed that this is still reproducible on the latest Microsoft Store package available to me:

Codex Desktop MSIX: 26.814.5517.0 (Store-signed, package status Ok)
Bundled desktop release reported in the app log: 26.814.41957
Windows 11 Pro x64: 10.0.26200

Additional controlled evidence:

Before restarting the app, all affected threads.rollout_path entries had been normalized to ordinary C:\... paths and the \\?\-prefix count was verified as zero.
A normal thread/archive operation then succeeded for a repaired test thread.
After installing 26.814.5517.0, launching that package, and resuming two active threads, both SQLite rows were written again with the verbatim \\?\C:\... form in both cwd and rollout_path.
SQLite integrity_check remains ok; every referenced rollout JSONL exists and is non-empty.

This reproduces the state transition described in this issue and indicates that 26.814.5517.0 still contains the resume/writer vs. archive path-form mismatch. No usernames, absolute paths, thread IDs, task content, raw logs, or database files are included here.

Independent confirmation on Windows x64 with Codex Desktop 26.814.5167.0.

Two unrelated local project threads reproduce the same archive failure:

failed to archive session: thread-store internal error:
failed to archive thread: The system cannot find the file specified. (os error 2)

Read-only checks before each attempt:

Both state_5.sqlite.threads.rollout_path values use the \\?\C:\... verbatim form.
Both rollout JSONL files exist and are readable (approximately 7.15 MB and 23.86 MB).
archived_sessions exists; source and destination are on the same volume; no destination-name collision exists.
Both rows remain archived = 0 after failure.
PRAGMA quick_check returns ok.
Restarting the app and signing in again do not change the result.
Ten other threads archived successfully in the same installation.
A read-only blast-radius count found 44 active rows using the verbatim prefix. This does not claim all 44 were tested.

The second affected thread is from the primary project checkout rather than the managed worktree used by the first, so missing Git-worktree metadata is not required to reproduce the failure. This independently supports the mixed-path/double-move diagnosis in the issue body.

Additional independent confirmation with a deterministic mitigation/regression test.

Environment

Codex Desktop MSIX: 26.814.5167.0
Windows x64
Eight affected local threads across three unrelated working directories

Controlled A/B reproduction

With state_5.sqlite.threads.rollout_path stored as \\?\C:\…, the normal thread/archive call consistently returned:
failed to archive thread: The system cannot find the file specified. (os error 2)
The rollout JSONL existed and was readable through both the verbatim and ordinary path spellings; both resolved to the same file and byte length.
Changing only the stored path spelling to ordinary C:\… made the same archive call succeed immediately.
Archive/unarchive left the transcript intact and SQLite integrity checks remained ok.

Persistent local mitigation test

As a diagnostic mitigation, I added two SQLite AFTER INSERT / AFTER UPDATE OF rollout_path triggers that strip a leading \\?\ prefix. This is not proposed as an end-user workaround; it was used to test whether preventing mixed path forms eliminates the failure.

Results:

A deliberately injected \\?\ path was normalized by the trigger in the same write.
13 real archive operations and 13 matching unarchive operations completed successfully.
All eight previously affected threads completed at least one archive/unarchive cycle.
Final state: zero verbatim rollout_path rows, all eight rollouts present in sessions, no stale archived copies, and PRAGMA integrity_check = ok.

This strengthens the conclusion that the failure is caused by mixed Windows path representations rather than missing files, permissions, authentication, or subscription state. Normalizing persisted rollout paths or deduplicating canonical source paths before scheduling renames should prevent the double-move.

Privacy note: no usernames, absolute paths, file or project names, thread IDs or titles, conversation content, database files, or raw logs are included.

Independent read-only confirmation from another Windows installation; the bug is still reproducible on the current Store package.

Environment

Codex Desktop MSIX: 26.814.5517.0 (package status Ok)
Bundled CLI / app-server: 0.148.0-alpha.15
Windows 11 Pro for Workstations x64, build 26200
Local Codex threads

Observed failure

Multiple unrelated threads repeatedly failed through the normal Desktop archive UI on 2026-08-19:

method=thread/archive
errorCode=-32603
failed to archive session: thread-store internal error:
failed to archive thread: 系统找不到指定的文件。 (os error 2)

The UI successfully issued each archive request; the failure came from the local thread store.

Read-only verification

Three separately inspected failing threads all had threads.rollout_path stored in the verbatim \\?\C:\...\ form.
Every referenced rollout JSONL exists and is readable.
Full database/file parity check:
- 116 active thread rows
- 61 archived thread rows
- 0 active rows reference a missing rollout file
- 0 archived rows reference a missing rollout file
12 active rows use the verbatim path prefix; 0 archived rows do.
The archive directory exists and previously archived threads remain readable.
No archive-related setting or disable flag is present in the user configuration.
Listing archived threads succeeds, so the failure is isolated to the local archive move/path handling.

This independently supports the mixed-path/double-move diagnosis in this issue. No usernames, absolute paths, thread IDs, project names, conversation content, credentials, raw logs, or database files are included. No local files or database records were modified during diagnosis.

Additional independent confirmation from the current Windows Store package.

Environment

ChatGPT/Codex package: 26.814.5517.0 (package status Ok; Store updater reported no newer package)
Bundled app-server: 0.148.0-alpha.15
Windows 11 Pro x64, build 26200
System locale: zh-CN
Local threads originally indexed with source = vscode and history_mode = legacy

Observed failure

Six archive attempts over approximately eight minutes all returned:

method=thread/archive
errorCode=-32603
failed to archive session: thread-store internal error:
failed to archive thread: 系统找不到指定的文件。 (os error 2)

The affected state_5.sqlite.threads.rollout_path begins with the exact Windows verbatim prefix described in the issue body.

Read-only verification found:

The referenced rollout JSONL exists and is readable.
All 135 JSONL records parse successfully.
PRAGMA integrity_check returns ok.
PRAGMA foreign_key_check returns no violations.
The row remains archived = 0 and archived_at IS NULL after every attempt.
The archive destination directory exists.
A separate thread/delete request succeeded during the same app session, which narrows the failure to the archive path/move logic rather than general filesystem permissions, authentication, or network state.
Both currently indexed active threads use the verbatim path form; only one was used for the repeated archive reproduction.

This closely matches the mixed-path/double-move diagnosis in the issue body. No usernames, absolute private paths, thread IDs, titles, conversation contents, credentials, raw logs, or database files are included. No local files or database records were modified during diagnosis.

We have a fix for this. It will be included in the next release.

Additional confirmation on the current Windows Store build.

Environment

Windows 11 Pro x64, build 26200
Microsoft Store package OpenAI.Codex 26.814.5517.0

At 2026-08-19 23:27:52 UTC, a normal Desktop archive action reached the local archive operation and failed with:

errorCode=-32603

failed to archive thread: The system cannot find the file specified. (os error 2)

Read-only verification found:

The affected task data file exists and is readable.
The local state database reports quick_check = ok.
The task remains unarchived after the failure.
The affected task metadata uses the extended Windows path form \\?\C:\….
All 37 active task records inspected reference existing data files, so this is not a missing-source-file case.

This closely matches the path-normalization failure described here and confirms that 26.814.5517.0 is still affected. I will retest after the next release containing the announced fix. No local paths, task IDs, titles, conversation content, account data, or raw logs are included, and no local state was modified.

Confirming this is exactly what I'm seeing on Windows. The annoying part is that it looks random in the app, but after checking the local state it isn't.

My setup:

Codex Desktop 26.814.5167.0
bundled CLI 0.148.0-alpha.15
Windows 11 x64

Right now I have 10 active user chats and 9 of them have a \\?\C:\... rollout path. SQLite quick_check is clean, and every affected JSONL file exists and is readable using either path spelling.

One extra data point that may help: I happened to have two backup snapshots of state_5.sqlite taken six minutes apart. In the first snapshot, a newly created active chat had a normal C:\... rollout path. In the second snapshot, that exact same row had been rewritten to \\?\C:\.... It was still unarchived, the file had not moved, and updated_at_ms had only increased by 1. I did not manually edit that chat between the snapshots.

I also tested the workaround on three unrelated affected chats: back up the databases, strip only the \\?\ prefix from that chat's rollout_path, then run the bundled archive command. All three archived successfully and moved into archived_sessions. Without that normalization, the same chats fail with os error 2.

So this does seem to be the resume/refresh path rewrite causing the same physical file to be queued twice, not missing history or a bad rollout file. It would be great if the archive code could dedupe after canonicalization, since otherwise reopening a chat can put it right back into the broken state.

Additional user-visible side effect confirmed on Codex Desktop 26.814.5517.0, bundled app-server 0.148.0-alpha.15, Windows 11 Pro 10.0.26200:

Resume an existing local thread, causing its persisted rollout path to use the \?\ form.
Archive it from the Desktop sidebar. thread/archive fails with -32603 / os error 2.
Despite the archive failure, the app-server clears the thread listener and shuts down the session.
Further composer submissions to the same still-visible thread fail with turn/start -32600: thread not found, surfaced by the UI as an error creating the chat, until the app is restarted.

The rollout file still exists and SQLite integrity checks remain ok. Stripping the prefix while the app is closed is not persistent because resume/refresh writes it back. After the failed archive tears down the listener, normalizing the path again and calling thread/archive without reopening the thread succeeds.

Besides the announced path fix, archive failure should not leave the visible thread unloaded and unusable. I can retest both behaviors when the next release is available.

Additional confirmation from the same Windows installation after attempting to clean up several affected tasks.

Environment

ChatGPT/Codex Microsoft Store package: 26.814.5517.0
Bundled app-server/CLI: 0.148.0-alpha.15
Windows, local Codex tasks

Observed

Seven older tasks had all referenced rollout files present but could not be archived through the normal thread/archive path; each returned the os error 2 failure described here.
After those tasks were repaired locally, the currently resumed task independently became unarchivable through the Desktop UI.
Read-only verification shows that the current task's rollout_path and cwd were re-persisted with the Windows verbatim-path prefix described in this issue.
The referenced rollout JSONL exists and is readable, and the task remains archived = 0.

This confirms the failure remains reproducible on 26.814.5517.0 and that repairing individual rows does not prevent resumed tasks from re-entering the broken path form. I understand from the maintainer update above that a fix is expected in the next release.

No usernames, absolute private paths, task IDs, titles, conversation contents, credentials, raw logs, or database files are included.

Additional independent confirmation from another Windows installation on the current Store build.

Environment

Codex Desktop package: 26.814.5517.0
Windows x64
Local Codex tasks

Local scope and reproduction

A read-only audit of state_5.sqlite found:

318 unarchived thread rows
43 unarchived rows whose rollout_path starts with the Windows verbatim prefix \\?\C:\...

Two unrelated completed tasks with this path form both failed through the normal thread/archive operation with:

failed to archive session: thread-store internal error:
failed to archive thread: The system cannot find the file specified. (os error 2)

For both tasks, the referenced rollout JSONL existed and was readable.

After backing up the database and rollout files, removing only the leading \\?\ from each selected row's rollout_path allowed the normal archive operation to succeed immediately. One task remained archived. The other was later referenced/reloaded by the running Desktop app and its row was written back to the \\?\ form with archived = 0, confirming that repairing individual rows is not durable while resume/refresh can reintroduce the verbatim path.

This matches the path-normalization/double-move diagnosis and confirms that build 26.814.5517.0 remains affected at scale. No usernames, private paths, thread IDs, titles, conversation contents, credentials, database files, or raw logs are included.

Independent confirmation on two Windows PCs, including the current 26.814.5517.0 MSIX package.

Primary PC:

Codex Desktop release shown by the app: 26.814.41957
MSIX package: OpenAI.Codex_26.814.5517.0_x64
Archiving fails for both recently created and older local Codex threads, across unrelated projects. This is not limited to migrated/legacy sessions.
The app-server log records method=thread/archive, JSON-RPC errorCode=-32603, followed by:

failed to archive session: thread-store internal error: failed to archive thread: 系统找不到指定的文件。 (os error 2)

The referenced rollout JSONL files exist and are readable, and the archive destination directory exists.
Read-only inspection found active thread rows using Windows verbatim \\?\D:\... rollout paths, while archived rows did not use the \\?\ form. No SQLite rows or session files were modified.

Second PC:

A separate Windows PC reproduces the same “Unable to archive conversation” UI failure. Its backend version/logs have not yet been collected, so I am not claiming the exact internal path state on that machine.

The new-thread and cross-machine reproduction supports a current Windows client/thread-store regression rather than a one-off path migration or a missing rollout file. No usernames, project paths, thread IDs, conversation titles/content, database files, or raw logs are included here.

Confirmed on a newer Windows Desktop build with the same deterministic sequence.

Environment:

Codex Desktop 26.814.5517.0 (Microsoft Store; updater reports NoUpdates)
Bundled/task app-server version 0.148.0-alpha.15
Windows x64

Observed:

With a plain C:\... value in threads.rollout_path, archive succeeds.
Restoring/opening the thread logs successful thread/read followed by thread/resume.
Immediately afterward, the same DB row contains \\?\C:\....
Archive then fails with:
failed to archive session: thread-store internal error: failed to archive thread: The system cannot find the file specified. (os error 2)
The rollout JSONL still exists and is readable; SQLite integrity check is ok, directory ACLs are valid, and both path spellings resolve outside the archive flow.
Normalizing only rollout_path and archiving without reopening succeeds; reopening reintroduces the prefix and the failure.

This also reproduces after updating from 26.814.5167.0 to 26.814.5517.0, so the issue appears to remain present in the current Store build available on 2026-08-20.

I initially opened #39600 before finding this exact report; I am closing it as a duplicate of this issue.

Additional deterministic trigger from Codex Desktop on Windows:

Archive an ordinary thread successfully.
Unarchive that same thread.
Immediately after thread/unarchive, the row changes from:
- archived = 1
- rollout_path = C:\Users\<user>\.codex\archived_sessions\rollout-<thread-id>.jsonl
to:
- archived = 0
- rollout_path = \\?\C:\Users\<user>\.codex\sessions\YYYY\MM\DD\rollout-<thread-id>.jsonl
Archiving it again consistently fails with -32603 / os error 2.
An immediate retry fails identically. The rollout file still exists because the first move is rolled back.

Environment:

Codex Desktop package: 26.814.5517.0
Bundled app-server: 0.148.0-alpha.15
Windows x64

This identifies thread/unarchive itself as another deterministic producer of the mixed Windows path representation, in addition to resume/refresh. Please include archive -> unarchive -> archive in the Windows regression coverage for the announced fix.

No usernames, private paths, thread IDs, titles, conversation content, or raw logs are included.

Independent confirmation on Windows 11.

Environment:

Codex Desktop package: 26.814.5517.0
Windows 11 x64, build 26200
Affected rows were created by bundled CLI/app-server versions 0.147.0-alpha.6.6, 0.148.0-alpha.9, and 0.148.0-alpha.15

Observed:

Archiving fails from both the Desktop UI and the app task-management set_thread_archived operation.

The localized error is:

failed to archive session: thread-store internal error:
failed to archive thread: 系統找不到指定的檔案。 (os error 2)

("The system cannot find the file specified.")

Reproduced deterministically on 13 distinct inactive local threads.
For every affected row:
- state_5.sqlite.threads.rollout_path begins with the Windows verbatim prefix \\?\
- the exact recorded rollout path exists and is readable
- archived=0 after the failure
In the same cleanup batch, four other local threads archived successfully and now have ordinary non-verbatim paths under archived_sessions.
Restarting/retrying through the UI does not help.

This strongly matches the duplicate physical-path analysis in this issue: the source rollout is present, but the normal and \\?\ forms appear to be treated as separate entries before canonicalization.

No rollout contents, private paths, or thread IDs are included here.

As I said above, we have a fix for this. It will be included in the next release. No need for additional confirmations or repros.

Independent confirmation with a deterministic lifecycle repro on Codex Desktop for Windows.

Reproduction

Start with a local thread that archives successfully.
Archive the thread.
- Archive succeeds.
Unarchive the same thread.
- Unarchive succeeds and the conversation remains intact.
Archive the same thread again.
- Archive fails with:

failed to archive session: thread-store internal error:
failed to archive thread: The system cannot find the file specified. (os error 2)

I have encountered this repeatedly: once an archived conversation is unarchived, attempting to archive it again can enter the broken state.

Local observation

For affected threads, state_5.sqlite.threads.rollout_path may be persisted with the Windows verbatim prefix:

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

The referenced .jsonl file still exists and is readable. After fully exiting Codex and backing up state_5.sqlite, removing only the leading \\?\ from the affected rollout_path allows the same thread to archive successfully without moving or deleting the rollout file.

The workaround is not durable: after another archive/unarchive/resume cycle, the prefixed path can return and the failure can recur.

Expected behavior

Archive/unarchive should be repeatable indefinitely:

archive -> unarchive -> archive -> unarchive -> ...

and equivalent Windows path representations (C:\... vs \\?\C:\...) should not cause thread-store state divergence or duplicate filesystem operations.

This adds a user-facing deterministic trigger to the existing diagnosis: archive -> unarchive -> archive can reproduce the problem repeatedly.

Navigation Menu

Repository navigation

Windows: `thread/archive` fails with "os error 2" after `thread/resume` stores a `\\?\` (verbatim) rollout_path — same file queued twice #39239

Summary

Environment

Repro

Analysis (`codex-rs/thread-store/src/local/archive_thread.rs`)

Suggested fix (either/both)

Environment

Affected threads

Confirmed workaround

Environment

Evidence before repair

Controlled repair

2 remaining items

Environment

Controlled A/B reproduction

Persistent local mitigation test

Environment

Observed failure

Read-only verification

Environment

Observed failure

Environment

Local scope and reproduction

Reproduction

Local observation

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows: thread/archive fails with "os error 2" after thread/resume stores a \\?\ (verbatim) rollout_path — same file queued twice #39239

Description

Summary

Environment

Repro

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

Suggested fix (either/both)

Activity

github-actions commented on Aug 18, 2026

ExecutiveDysfunctionGames commented on Aug 18, 2026

rikaduz commented on Aug 18, 2026

Environment

Affected threads

Confirmed workaround

louisaquino14 commented on Aug 19, 2026

railgun20001 commented on Aug 19, 2026

QinXi-ai commented on Aug 19, 2026

Environment

Evidence before repair

Controlled repair

tylor-bennett commented on Aug 19, 2026

RacYang commented on Aug 19, 2026

Mentaline commented on Aug 19, 2026

2 remaining items

binawoh commented on Aug 19, 2026

Environment

Controlled A/B reproduction

Persistent local mitigation test

13632675873 commented on Aug 19, 2026

Environment

Observed failure

Read-only verification

zoisythe commented on Aug 19, 2026

Environment

Observed failure

etraut-openai commented on Aug 19, 2026

iM3SK commented on Aug 20, 2026

monroedean commented on Aug 20, 2026

q153877011 commented on Aug 20, 2026

GNARGNARHEAD commented on Aug 20, 2026

goody0326 commented on Aug 20, 2026

Environment

Local scope and reproduction

ashjo42 commented on Aug 20, 2026

Smoo-G commented on Aug 20, 2026

Onlydreams commented on Aug 20, 2026

m123384268 commented on Aug 20, 2026

etraut-openai commented on Aug 20, 2026

yangqoor commented on Aug 20, 2026

Reproduction

Local observation

Expected behavior

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Windows: `thread/archive` fails with "os error 2" after `thread/resume` stores a `\\?\` (verbatim) rollout_path — same file queued twice #39239

Analysis (`codex-rs/thread-store/src/local/archive_thread.rs`)