Repository navigation
Codex Desktop shows Failed to resume chat toast after archiving a chat #26159
Description
Summary
When archiving a chat from Codex Desktop, the archive operation succeeds, but the Desktop frontend immediately attempts to resume the same now-archived thread. The app server correctly rejects thread/resume with session ... is archived, and Desktop surfaces that as a red "Failed to resume chat" toast.
This makes successful archive actions look like failures and can repeat until the user navigates away.
Environment
- Codex Desktop client version:
26.601.21317 - Codex CLI/session version seen in archived session metadata:
0.136.0-alpha.2 - OS: macOS
- Date observed: 2026-06-03
Steps to reproduce
- Open Codex Desktop.
- Open or select an existing local chat.
- Archive the chat from the recent tasks/menu UI.
- Observe the red toast:
Failed to resume chat
session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first.
Expected behavior
After archiving a chat, Desktop should remove/navigate away from that chat without attempting to resume it. No failure toast should appear when the archive succeeded.
Actual behavior
The archive request succeeds, but Desktop sends a thread/resume request for the archived conversation shortly afterward. The backend rejects the resume request because the thread is archived, which is correct server-side behavior, but the frontend turns that expected rejection into a user-visible error.
Evidence
The durable thread DB showed the archive itself succeeded:
archived=1
archived_at=<archive_timestamp>
rollout_path=<codex_home>/archived_sessions/<archived_rollout_file>.jsonl
The transcript was no longer present under the active sessions directory and existed under the archived sessions directory, so this does not appear to be a failed archive or corrupt archive state.
Desktop log sequence, with local IDs redacted:
T+0ms info [electron-message-handler] Archive requested conversationId=<thread_id> source=recent_tasks_menu
T+61ms info [AppServerConnection] response_routed ... method=thread/archive ... errorCode=null
T+137ms info [AppServerConnection] response_routed ... method=thread/resume ... errorCode=-32600
T+137ms error [electron-message-handler] Request failed conversationId=<thread_id> ... method=thread/resume ... error={"code":-32600,"message":"session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first."}
T+138ms error [electron-message-handler] Failed to resume conversation conversationId=<thread_id> errorMessage="session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first." errorStack="Error: session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first.\n at Object.postMessage (app://-/assets/vscode-api-<hash>.js:1:<offset>)\n at Object.error (app://-/assets/vscode-api-<hash>.js:1:<offset>)\n at app://-/assets/local-conversation-thread-<hash>.js:41:<offset>"
I also saw the same pattern for other archived chats:
T+0ms method=thread/archive conversationId=<other_thread_id> errorCode=null
T+43ms method=thread/resume conversationId=<other_thread_id> errorCode=-32600
Suspected root cause
The active route/sidebar/thread component still has the archived conversation selected after a successful archive and its hydration/resume effect continues to call thread/resume. The server-side archived-thread guard is behaving correctly; the Desktop client should either navigate away, clear the selected thread, or suppress resume/hydration for archived threads after thread/archive succeeds.
Activity
github-actions commentedon Jun 3, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
session is archived#25769Powered by Codex Action
d19dotca commentedon Jun 4, 2026
I am seeing this as well. Only noticed this in the latest build
Version 26.601.21317 • Released Jun 2, 2026on macOS (Apple silicon).m-mohamed commentedon Jun 4, 2026
Adding one more current macOS repro with app-server/thread-store evidence. This looks closely related to #25769 and #23246, but I am commenting here because this issue already has the
appandapp-serverlabels and the behavior I saw crosses both surfaces.Environment
26.601.21317, build3511codex-cli 0.136.0-alpha.2codex-cli 0.136.026.3build25D125arm64codex doctor --summary --ascii: app-server running in persistent mode; thread diagnostics report archive/state driftRepro
Local State Evidence
The active list no longer includes the thread:
The archived search finds it:
Reading the thread succeeds and shows it has moved under archived sessions:
The local state DB also says the thread is archived:
codex doctor --summary --asciialso reports:Expected
Once archive succeeds at the thread-store/app-server level, Codex Desktop should either:
It should not keep the archived row selectable in the active sidebar, and a second archive attempt from the UI should not fail because Desktop is acting on stale state.
Hypothesis
The thread-store/app-server archive path is doing the right thing, but Desktop sidebar/catalog/cache state is not fully reconciling with the archived state after archive. In this repro the active list omitted the thread, archived search found it, and SQLite had
archived = 1, while the Desktop sidebar still rendered the row.This may be the same underlying class as #25769, and it also overlaps with #23246 where archived rows remain visible in Desktop.
I avoided attaching screenshots because my sidebar contains unrelated private project names. Happy to test a build, run a specific diagnostic command, or prepare an invited PR if this matches the team’s intended direction.
etraut-openai commentedon Oct 13, 2026
(response from codex)
Thanks for the macOS confirmations. Closing as a duplicate of #25713: in both cases archiving succeeds but the Desktop tries to resume the same archived thread, causing the misleading error or loop. That tracker includes macOS as well as Windows evidence and will remain open.