Codex Desktop shows Failed to resume chat toast after archiving a chat

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

1. Open Codex Desktop.
2. Open or select an existing local chat.
3. Archive the chat from the recent tasks/menu UI.
4. 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.