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

Summary

On Codex Desktop for Windows, archiving the currently open local thread succeeds on the backend, but the Desktop UI immediately keeps trying to resume the same archived thread. This produces a repeated thread/resume / thread/goal/get error loop, a misleading archive failure/error experience, and the app becomes very hard to interact with until it is force-quit/restarted.

This appears related to session/thread resume + archive state handling, but the observed trigger is specifically archiving the active/open conversation from the Desktop UI.

Environment

Product: Codex Desktop
Platform: Windows 10 x64 (10.0.19045 observed locally)
Codex Desktop package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
Bundled app-server/client version in logs: 26.527.7698
Local state/log storage: %USERPROFILE%\.codex, %LOCALAPPDATA%\Codex\Logs

Symptoms

User right-clicks / archives the currently open chat.
The UI reports or appears to report archive failure.
Codex Desktop becomes sluggish/frozen. Mouse clicks in the app are delayed or ineffective; user has to force close from the Windows taskbar and relaunch.
After relaunch, the thread is actually archived, so the archive operation itself succeeded.

Local Evidence

Example affected thread, redacted metadata:

thread id: 019e856b-308d-7b73-811e-88d142e5f99a
thread title: <redacted>
cwd: <redacted Windows project path>
state_5.sqlite: archived=1
archived_at: 2026-06-02 07:11:43 local time

Desktop log around the failure:

2026-06-01T23:11:43.507Z info [AppServerConnection] response_routed ... conversationId=019e856b-308d-7b73-811e-88d142e5f99a ... errorCode=null ... method=thread/archive ... targetDestroyed=false
2026-06-01T23:11:43.520Z error [electron-message-handler] Conversation state not found conversationId=019e856b-308d-7b73-811e-88d142e5f99a
2026-06-01T23:11:45.403Z info [AppServerConnection] response_routed ... conversationId=019e856b-308d-7b73-811e-88d142e5f99a ... errorCode=-32600 ... method=thread/resume ... targetDestroyed=false
2026-06-01T23:11:45.411Z error [electron-message-handler] Request failed ... method=thread/resume ... error={"code":-32600,"message":"session 019e856b-308d-7b73-811e-88d142e5f99a is archived. Run `codex unarchive 019e856b-308d-7b73-811e-88d142e5f99a` to unarchive it first."}
2026-06-01T23:11:45.412Z error [electron-message-handler] Failed to resume conversation conversationId=019e856b-308d-7b73-811e-88d142e5f99a errorMessage="session 019e856b-308d-7b73-811e-88d142e5f99a is archived. Run `codex unarchive ...` to unarchive it first."
2026-06-01T23:11:45.427Z info [AppServerConnection] response_routed ... errorCode=-32600 ... method=thread/goal/get ...
2026-06-01T23:11:45.428Z error [electron-message-handler] Request failed ... method=thread/goal/get ... error={"code":-32600,"message":"thread not found: 019e856b-308d-7b73-811e-88d142e5f99a"}

The same sequence repeated every ~2-3 seconds until the user force-quit the app. In one earlier repro on the same machine, a similar archived-thread loop produced roughly:

~85 seconds after archive
164 related events
32 Failed to resume conversation events
64 thread/goal/get attempts

For each affected thread checked locally, thread/archive returned errorCode=null, and state_5.sqlite had archived=1. The failure is after archive, when the renderer/app state continues to route/resume the archived conversation.

Steps to Reproduce

Open a normal local Codex Desktop thread on Windows.
While the thread is still the active/open conversation page, archive that same thread from the Desktop UI.
Observe that the archive request succeeds in logs (method=thread/archive, errorCode=null).
Immediately after, the app logs Conversation state not found, then repeatedly issues thread/resume and thread/goal/get for the archived thread.
The UI becomes sluggish/frozen and may show a misleading failure/error state. Force-quitting and relaunching shows the thread is actually archived.

Expected Behavior

After archiving the active/open thread, Desktop should navigate away from that thread or otherwise stop all resume/goal hydration attempts for it. The UI should not repeatedly try to resume a thread that was just archived successfully.

Actual Behavior

Desktop remains bound to the archived thread and repeatedly tries to resume/hydrate it. The backend correctly rejects resume because the session is archived, but the renderer/app state appears to retry until the app is closed.

Notes

This seems adjacent to other session/thread archive-resume issues, but the local repro here is specifically:

Windows Desktop build 26.527.7698.0
archive active/open thread
backend archive succeeds
UI loops on thread/resume and thread/goal/get for the same archived conversation
app becomes difficult to interact with until restart

I can provide more sanitized log excerpts if useful.

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

Codex Desktop (Windows): UI-archived conversations reappear in active sidebar after refresh, and archive triggers flashing terminal cleanup #25541
Windows Codex Desktop fails to launch after reinstall - Unable to find Electron app / archived session errors #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.

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:

Archive a non-active chat: works.
Archive the currently active/open chat: archive succeeds, but Desktop keeps trying to resume/hydrate that archived thread.
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

The Archive action should be single-flight/debounced, or thread/archive should be idempotent.
Once any archive request succeeds, later no rollout found responses from duplicate requests should not override the successful UI state.
The renderer should unsubscribe/stop hydrating the archived thread and release rollout file handles.
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

Archiving a local thread initially failed with:

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

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

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

Navigation Menu

Repository navigation

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

Summary

Environment

Symptoms

Local Evidence

Steps to Reproduce

Expected Behavior

Actual Behavior

Notes

Environment

Observed sequence

Expected behavior

Environment

Observed sequence

Additional evidence

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Symptoms

Local Evidence

Steps to Reproduce

Expected Behavior

Actual Behavior

Notes

Activity

github-actions commented on Jun 1, 2026

FuturiaMarketing commented on Jun 3, 2026

mr-ashawa commented on Jun 4, 2026

szsip239 commented on Jul 20, 2026

Environment

Observed sequence

Expected behavior

packye commented on Jul 29, 2026

zelingu0920-ctrl commented on Aug 18, 2026

Environment

Observed sequence

Additional evidence

Expected behavior

zelingu0920-ctrl commented on Aug 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions