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

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

• #39209
• #39150
• #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:

1. 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.
2. A normal thread/archive operation then succeeded for a repaired test thread.
3. 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.
4. 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 confirmation from Codex Desktop on Windows.

• In-app feedback ID: 01a018a3-51b5-7763-af37-a2c3b6cc28e2
• App-server client: 26.814.41407
• The affected local thread's state_5.sqlite.threads.rollout_path uses the extended Windows path form \\?\C:\Users\<user>\.codex\sessions\...\rollout-...jsonl.
• The referenced rollout file exists, is readable, and parses successfully with 1,720 items and zero parse errors.
• After a full app restart, archiving the thread while it is notLoaded still returns:

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

• After failure, archived remains 0, the original rollout remains in sessions, no archived copy is created, and no writer lock remains.
• A failed archive attempt can also leave the thread returning thread not found when continuing the conversation until the app is restarted.
• No SQLite rows or original session files were manually modified; only a verified backup was created before retrying.

This behavior closely corroborates the duplicate-move/path-normalization diagnosis described in this issue. The rollback preserves the rollout file, but the archive fails and can temporarily leave the runtime thread unresolvable.

Independent confirmation after installing the newer Windows MSIX build: the issue is still reproducible. Environment: - Codex Desktop package 26.814.5517.0 - app-server 0.148.0-alpha.15 - Windows 11 Pro x64 10.0.26200 Two unrelated local threads failed to archive on 26.814.5167.0. After updating to 26.814.5517.0, retrying one of them still returns: ``text failed to archive session: thread-store internal error: failed to archive thread: Не удается найти указанный файл. (os error 2) ` Read-only verification: - the affected threads.rollout_path values use the \\?\C:\... form - the referenced rollout JSONL files exist, are readable, and contain the matching session IDs - the rows remain archived = 0, with no archived duplicate after failure - SQLite integrity checks pass - one affected rollout had previously passed through a local import/sync workflow, while the other had never been touched by it; both fail identically - an older Desktop build (26.810.52044) could resume the same rollout, and archive operations had succeeded before the 26.814` update. No database rows or rollout files were modified during this investigation.

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:

1. Resume an existing local thread, causing its persisted rollout path to use the \\?\ form.
2. Archive it from the Desktop sidebar. thread/archive fails with -32603 / os error 2.
3. Despite the archive failure, the app-server clears the thread listener and shuts down the session.
4. 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:

1. With a plain C:\... value in threads.rollout_path, archive succeeds.
2. Restoring/opening the thread logs successful thread/read followed by thread/resume.
3. Immediately afterward, the same DB row contains \\?\C:\....
4. 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)

1. 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.
2. 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:

1. Archive an ordinary thread successfully.
2. Unarchive that same thread.
3. 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

1. Archiving it again consistently fails with -32603 / os error 2.
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

1. Start with a local thread that archives successfully.
2. Archive the thread.

• Archive succeeds.

1. Unarchive the same thread.

• Unarchive succeeds and the conversation remains intact.

1. 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.