›_ Codex Issues
Codex Issues / #39471

Windows Desktop: all local thread archives fail with thread-store os error 2 although rollout paths exist

Open 💬 4 comments Opened Aug 19, 2026 by Jaydon-L
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

Codex Desktop 26.814.41407 on Windows. The affected threads report bundled CLI versions including 0.148.0-alpha.15.

What subscription do you have?

ChatGPT subscription (exact tier omitted because the failure is entirely local and reproduces through thread/archive).

What platform is your computer?

Windows 11 x64.

What issue are you seeing?

Every local Codex thread now fails to archive from both the Desktop sidebar and the app's set_thread_archived task-management interface.

The app-server returns JSON-RPC error -32603:

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

The localized Windows message means "The system cannot find the file specified."

This is not a missing rollout file:

  • state_5.sqlite.threads.rollout_path exactly matches the existing rollout JSONL path.
  • The source JSONL exists, is readable, and has normal file attributes.
  • Both ~/.codex/sessions and ~/.codex/archived_sessions are real directories, not symlinks or junctions.
  • The archive directory exists and the user has full control.
  • There is no same-name destination file.
  • After each failure, archived=0, archived_at IS NULL, and the rollout remains in sessions.
  • Restarting Desktop and confirming all Codex processes exited does not help.
  • Retrying after the target thread listener was torn down still returns the same os error 2.
  • The failure reproduces across multiple unrelated, valid threads rather than one corrupt conversation.

The Desktop log sequence is consistently:

Archive requested ... source=recent_tasks_menu
response_routed ... errorCode=-32603 ... method=thread/archive
Request failed ... "failed to archive session: thread-store internal error: failed to archive thread: 系统找不到指定的文件。 (os error 2)"

The same error is returned when the archive call comes from source=dynamic_tool, so this is below the renderer/UI layer.

When did this start?

Archiving previously worked on this machine. Desktop logs contain many successful thread/archive responses, including a successful archive on the same Desktop release 26.814.41407 on 2026-08-18. The first confirmed failures appeared on 2026-08-19, after which all tested local threads failed.

This suggests a thread-store state/path-resolution transition rather than a simple account, network, permissions, or app-version issue.

Steps to reproduce

  1. Start Codex Desktop on Windows.
  2. Select any ordinary completed local Codex thread.
  3. Use the sidebar Archive action.
  4. Observe the red "Failed to archive conversation" toast.
  5. Call thread/archive through the app task-management interface for the same or another valid local thread.
  6. Observe the same -32603 / os error 2 response.
  7. Verify that the rollout still exists at the exact DB-recorded path and the DB row remains unarchived.

Expected behavior

The rollout should move from sessions/YYYY/MM/DD/ to archived_sessions/, and the thread row should be updated atomically to archived=1 with the archived rollout path.

Additional information

Possibly related to #28276, but this report provides a reproducible Windows app-server error and verifies that the DB-recorded source file actually exists.

The current error loses the failing filesystem path. Please preserve the source/destination or failing auxiliary path in the ThreadStoreError::Internal context so Windows os error 2 can be diagnosed precisely.

No rollout files or SQLite rows were manually moved or edited during diagnosis.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 9 days ago

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

  • #39468
  • #39239
  • #39130
  • #39146
  • #39275

Powered by Codex Action

Jaydon-L · 9 days ago

Additional local diagnosis confirms a Windows path-format regression.\n\nObserved correlation:\n- Every confirmed failing thread tested (4/4) had its SQLite threads.rollout_path stored with the Windows extended-length prefix: \\?\\C:\\Users\\<user>\\.codex\\sessions\\...\n- 118 other active rows and all 67 archived rows used ordinary C:\\... paths at the time of inspection.\n- Successfully unarchiving an older thread rewrote its active rollout_path using the \\?\\ prefix; trying to archive that restored thread then failed with the same os error 2.\n\nControlled test on one affected thread:\n1. Created a consistent SQLite online backup and verified both backup and live DB with PRAGMA quick_check = ok.\n2. Changed only that thread's rollout_path from \\?\\C:\\... to C:\\... (same existing JSONL, no other row fields changed).\n3. Called the normal Codex thread/archive API.\n4. Archive succeeded immediately. The source disappeared from sessions, appeared in archived_sessions, and SQLite changed to archived=1 with the ordinary archived path.\n\nControl filesystem tests also succeeded in both directions, including mixed extended/ordinary path forms, so Windows permissions, the volume, and the two directories themselves are not generally blocking rename.\n\nThis makes the \\?\\-prefixed rollout_path handling in Codex's archive pipeline the confirmed trigger on this machine. The unarchive path appears to introduce the problematic representation.

Hzzz7 · 8 days ago

Additional independent reproduction on a newer Windows Desktop build

Environment:

  • Codex Desktop: 26.814.5517.0
  • Windows 11 Pro x64, build 26200
  • The user fully restarted Codex Desktop before retesting; the failure persists.

Observed behavior:

  • Archive fails for many unrelated local threads, not just one conversation or project. The tested set includes a pending-task thread, a model-query thread, a normal AI-software thread, a handoff-created successor thread, and older project threads.
  • The UI reports that the conversation cannot be archived. The local backend log records the localized Windows file-not-found error:
failed to archive session: thread-store internal error: failed to archive thread: 系统找不到指定的文件。 (os error 2)
  • The referenced rollout JSONL files remain present and readable. The local thread records remain archived=0 with archived_at unset after each failure. No database rows or rollout files were edited during diagnosis.
  • Restarting the app does not change the result.

The local state also shows the same path-format correlation reported in this issue: affected active rows use a Windows extended-length \\?\ prefix in rollout_path, while successfully archived rows use ordinary C:\... paths. This is consistent with the duplicate/canonical-path move failure described in the existing root-cause follow-ups.

There is a related web persistence symptom: archiving from Codex Web temporarily removes the conversation, but it reappears in the active list after a page refresh.

The separate muse-spark-1.2 is not supported model-selector error was observed in another context and is not being presented as the cause of this archive failure.

This reproduction extends the issue to Desktop 26.814.5517.0 and confirms that the failure remains after restart and across unrelated threads. Please consider a regression test covering active local rows with \\?\ rollout paths, repeated archive attempts, and persistence across client restart/web refresh.

cavintank · 8 days ago

I can reproduce this on Codex Desktop for Windows with a local task.

  • Archiving from the desktop UI shows an archive-failed toast.
  • Retrying through the supported task-management archive action also fails.
  • The backend reports a thread-store internal error with Windows os error 2.
  • The task remains in the active list, so the supported archive-then-delete workflow is blocked.

No logs, file paths, thread identifiers, account details, or conversation contents are included here.