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

1. Open a normal local Codex Desktop thread on Windows.
2. While the thread is still the active/open conversation page, archive that same thread from the Desktop UI.
3. Observe that the archive request succeeds in logs (method=thread/archive, errorCode=null).
4. Immediately after, the app logs Conversation state not found, then repeatedly issues thread/resume and thread/goal/get for the archived thread.
5. 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.