Codex Desktop Windows: archiving the active thread succeeds, then UI repeatedly resumes archived thread and freezes

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

• #25541
• #25674

Powered by Codex Action

I am seeing the same active-thread archive/resume behavior on Windows.

Environment:

Windows 11 Pro 64-bit, build 26200
Codex Desktop package: OpenAI.Codex 26.601.2237.0
codex-cli: 0.130.0-alpha.5

Observed UI error after archiving the currently open chat:

Impossibile ripristinare la chat
session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first.

This matches the diagnosis in this issue: the archive action appears to complete, but the Desktop UI remains bound to the just-archived active conversation and immediately tries to restore/resume the same thread instead of navigating away.

Expected behavior from the user perspective would be one of:

• switch to the next available non-archived chat;
• clear the active chat/view and show a new-chat/empty state;
• show an explicit archived/read-only state with an unarchive option.

In this case the user workspace/vault is on D: while Codex app/user state is on C:, but the error is keyed to the archived session id rather than a filesystem path. This looks like a stale active conversationId / route state problem, not a C: vs D: path confusion.

Current workaround: switch to another chat before archiving the target chat from the sidebar, or restart Codex if the UI gets stuck after archiving the active chat.

<img width="707" height="182" alt="Image" src="https://github.com/user-attachments/assets/4cd89026-4c0c-4937-9698-c9c64d9981eb" />
<img width="693" height="154" alt="Image" src="https://github.com/user-attachments/assets/a564e8bf-ea55-4882-bc65-65de6d4551cd" />

Additional confirmation / narrowed repro from my setup:

• After updating Codex CLI to 0.137.0, I can confirm that archiving works without errors if the chat being archived is not the currently active/open chat.
• The error appears only when archiving the chat that is currently active in the main/right pane.
• I also observed a related secondary symptom: before triggering the active-chat archive error, creating a new chat/task could fail with:

Error creating task: session <id> is archived. Run codex unarchive <id> to unarchive it first.

After the active-chat archive flow completed with the expected Failed to resume chat error for the same archived session, the “Error creating task” symptom disappeared.

This suggests that the create-task failure is likely another consequence of stale active conversation state: the UI still routes new task creation through the archived active conversation id until the archive/resume error path partially clears or refreshes that state.

So the narrowed repro seems to be:

1. Archive a non-active chat: works.
2. Archive the currently active/open chat: archive succeeds, but Desktop keeps trying to resume/hydrate that archived thread.
3. While the stale archived conversation id is still active, new chat/task creation may also fail with the same session is archived message.

Environment note: reproduced on Windows and macOS. Current CLI after update: codex-cli 0.137.0.

Confirming the same general failure mode on macOS, with an additional duplicate archive-dispatch race.

Environment

• Codex Desktop for macOS: 26.715.52143 (5591)
• Bundled CLI: codex-cli 0.145.0-alpha.18
• macOS 26.5.2 (25F84), Apple Silicon (arm64)
• Local thread; the affected rollout was unusually large: 4,918,595,444 bytes (~4.58 GiB)

Observed sequence

Archiving the thread from recent_tasks_menu produced three Archive requests in the same millisecond for the same conversation:

Archive requested ... source=recent_tasks_menu
Archive requested ... source=recent_tasks_menu
Archive requested ... source=recent_tasks_menu

The first request succeeded:

method=thread/archive durationMs=451 errorCode=null

The other two requests then failed because the first request had already moved the rollout:

method=thread/archive errorCode=-32600
no rollout found for thread id <redacted>
Archive skipped because thread has no active rollout

Backend/filesystem verification showed that the archive had actually succeeded:

• state_5.sqlite: archived=1
• rollout path points to archived_sessions
• no matching file remains under sessions
• exactly one matching file exists under archived_sessions

However, the Desktop UI did not consistently show the thread in Archived Threads and continued treating it as loaded. The renderer/app-server kept issuing thread/turns/list for that archived thread roughly every 10-15 seconds, with individual calls taking about 9-19 seconds.

The Codex app-server also continued to hold both read and writable file descriptors for the rollout after it had moved to archived_sessions. A native background archive request for the same thread subsequently did not return within 70 seconds.

Expected behavior

1. The Archive action should be single-flight/debounced, or thread/archive should be idempotent.
2. Once any archive request succeeds, later no rollout found responses from duplicate requests should not override the successful UI state.
3. The renderer should unsubscribe/stop hydrating the archived thread and release rollout file handles.
4. Archived Threads should reflect the backend state without requiring an app restart.

Restarting Desktop is currently required to release the loaded rollout before it can be safely moved to cold storage. I am not attaching the rollout because it contains private conversation data, but I can provide additional sanitized log lines if useful.

Additional Windows reproduction with a different archive failure path.

Environment

• Product: Codex Desktop for Windows
• Desktop/app-server client version in local logs: 26.721.41059
• Reproduced: 2026-07-29 11:48 CST
• UI language: Simplified Chinese

Observed behavior

• Archiving conversations showed the generic toast 无法归档对话 (Unable to archive conversation).
• A direct background archive attempt against five idle threads exposed the underlying error for every thread:

thread-store internal error: failed to archive thread:
The system cannot move the file to a different disk drive. (os error 17)

Confirmed local storage layout

• Active sessions: %USERPROFILE%\.codex\sessions on C: (real directory)
• Archived sessions: %USERPROFILE%\.codex\archived_sessions, a junction targeting D:\CodexData\codex\archived_sessions

This confirms that this particular reproduction is caused by the thread store attempting a cross-volume move through a directory junction. Windows cannot complete the rename/move operation atomically across C: and D:. It is therefore distinct from the successful-archive/stale-active-route loop originally reported in this issue, although the Desktop UI presents the same generic archive failure message.

Expected behavior

• Detect the cross-volume move error and fall back to a safe copy, flush/verify, and source removal operation; or
• show an actionable error explaining that sessions and archived_sessions must be on the same volume.

Actual behavior

• All archive attempts fail with a generic toast; the UI does not expose the cross-volume storage cause.

Local workaround
Keep both sessions and archived_sessions on the same volume. No project source code, account data, or business data is involved in this reproduction.

Additional Windows reproduction that appears to connect this issue with the \\?\ path-normalization problem reported in #26059.

Environment

• Codex Desktop: 26.814.5167.0
• Bundled Codex core: 0.148.0-alpha.15
• OS: Windows x64

Observed sequence

1. Archiving a local thread initially failed with:

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

1. The thread store's rollout_path used the Windows verbatim-path prefix:

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

The referenced file existed and was accessible through the equivalent normalized path without the prefix:

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

1. For diagnostic purposes, removing only the \\?\ prefix from this thread's stored rollout_path made the built-in archive operation succeed immediately. No conversation content was changed.

1. After the archive succeeded, the Desktop UI attempted to access the archived thread again and displayed:

thread not found: <REDACTED_THREAD_ID>

Backend verification showed that the thread was correctly marked archived and its rollout had moved to archived_sessions; the error occurred because the UI still requested the archived thread.

Additional evidence

• At the time of inspection, 10 unarchived local thread rows used the \\?\ prefix.
• Every referenced rollout file existed at its normalized Windows path.
• Normalizing only the affected path value changed the archive result from os error 2 to success.
• The subsequent thread not found behavior matches the stale active-thread state described in this issue.

Expected behavior

• Equivalent Windows paths with and without \\?\ should be normalized consistently.
• Archiving should succeed without a local database edit.
• After successful archive, Desktop should navigate away from the archived thread instead of requesting it again.

This suggests two related failure stages: a thread-store path-normalization failure before archive, followed by the stale active-thread/UI-state failure after archive. Usernames, full local paths, thread titles, conversation content, and thread IDs have been redacted.

Application feedback has also been submitted for this reproduction.

Feedback session ID: 01a015ef-6bba-7ac2-abdb-3f3ded74fb44

This feedback session corresponds to the Windows archive/path-normalization reproduction documented in my previous comment.