›_ Codex Issues
Codex Issues / #25769

Codex Desktop macOS: archiving the currently viewed chat leaves right pane on archived thread and triggers `session is archived`

Open 💬 10 comments Opened Jun 2, 2026 by 29988122
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Codex Desktop for macOS, archiving the currently viewed chat appears to succeed on the backend, but the Desktop UI does not navigate away from that chat. The right-side viewer remains bound to the just-archived thread, then the app immediately shows a red error/toast:

Failed to resume chat
session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first.

This looks like an active-thread navigation/state bug after thread/archive: the archived thread is still treated as the current resumable thread instead of the UI clearing the active route, switching to another non-archived thread, or showing a new-chat empty state.

This seems closely related to #25713, which reports the same active-thread-after-archive resume loop on Windows. This issue is for the same/similar behavior confirmed on macOS, with the visible symptom that the right pane/viewer stays on the archived chat.

Environment

  • Product: Codex Desktop
  • Platform: macOS / Darwin
  • Chat type observed: projectless/local chat
  • Exact Codex Desktop version: not collected yet
  • Bundled CLI version: not collected yet

Version can be collected with:

/Applications/Codex.app/Contents/Resources/codex --version

Steps to reproduce

  1. Open Codex Desktop on macOS.
  2. Open a local/projectless chat so it is the currently viewed active chat in the right-side viewer.
  3. Click Archive on that same currently viewed chat.
  4. Observe that the archive action appears to complete, but the right-side viewer remains on the same chat instead of navigating away.
  5. A red error/toast appears saying the same thread is archived and suggesting codex unarchive <thread_id>.

Expected behavior

After archiving the currently viewed/active chat, Codex Desktop should do one of the following:

  • clear the active conversation/viewer route and show a new-chat empty state;
  • navigate to the next available non-archived thread;
  • if the user is intentionally viewing an archived thread, show an archived/read-only/unarchive recovery state.

It should not call thread/resume or goal hydration on the thread it just archived.

Actual behavior

The archive itself appears to succeed, but the renderer/viewer remains bound to the archived thread. The app then tries to resume the same archived thread and shows:

session <thread_id> is archived. Run `codex unarchive <thread_id>` to unarchive it first.

This makes the archive action look like it failed, even though the underlying state is likely already archived.

Notes / likely cause

The important detail is that the thread id in the error is exactly the thread that was just archived. That suggests the issue is not a corrupt session and not a failed archive; rather, the active conversationId / route / viewer state is not cleared after a successful archive.

Potential client-side fix:

  • On successful thread/archive, if the archived thread id matches the currently active conversation id, immediately clear the active conversation id or navigate away.
  • Re-query/select only non-archived threads for the next active thread.
  • Guard thread/resume / thread/goal/get so they are not called for archived threads.
  • If no non-archived thread exists, display a new-chat empty state.

Workaround currently used

Avoid archiving the chat that is currently open in the right pane. Instead, first switch to a different/new chat, then archive the target chat from the sidebar. If already stuck, restarting the app or clearing UI/session storage can clear the stale active route; codex unarchive <thread_id> only restores the archived chat and is not desired when the user actually intended to archive it.

Related issues

  • #25713 — Same active-thread archive/resume loop reported on Windows.
  • #20317 — Archived local thread cannot be resumed after restore due to sessions/archived_sessions path mismatch.
  • #18216 — Archived thread route/deep-link lacks recovery UI.
  • #11907 — macOS app has archive/unarchive refresh gap.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #25713

Powered by Codex Action

krolord · 1 month ago

Additional confirmation from Codex Desktop on macOS. This reproduces for archiving the currently viewed/active thread: archive succeeds, then the UI repeatedly tries to resume the same archived conversationId and shows the red Failed to resume chat toast.

Environment observed:

  • Product: Codex Desktop on macOS
  • App bundled CLI: codex-cli 0.136.0-alpha.2
  • Homebrew CLI on PATH: codex-cli 0.136.0
  • Thread mode: local project thread
  • Session id from toast: 019e884c-78ce-7ea2-8218-b2035c938952

Local state checks after archiving:

  • Archive succeeded; the session moved to ~/.codex/archived_sessions/rollout-2026-06-02T08-26-13-019e884c-78ce-7ea2-8218-b2035c938952.jsonl.
  • The threads row in ~/.codex/state_5.sqlite had archived=1 and rollout_path pointing to archived_sessions.
  • codex doctor --summary --ascii reported state DBs healthy and threads rollout files and state DB thread inventory agree.

Relevant log pattern:

2026-06-02T12:26:52.615Z error [electron-message-handler] Request failed conversationId=019e884c-78ce-7ea2-8218-b2035c938952 ... method=thread/resume ... "session 019e884c-78ce-7ea2-8218-b2035c938952 is archived. Run `codex unarchive 019e884c-78ce-7ea2-8218-b2035c938952` to unarchive it first."
2026-06-02T12:26:52.616Z error [electron-message-handler] Failed to resume conversation conversationId=019e884c-78ce-7ea2-8218-b2035c938952 ...
2026-06-02T12:26:52.639Z error [electron-message-handler] Request failed conversationId=019e884c-78ce-7ea2-8218-b2035c938952 ... method=thread/goal/get ... "thread not found: 019e884c-78ce-7ea2-8218-b2035c938952"

The same archive-then-resume loop also appeared for another archived session in the same app log, so this does not appear isolated to one corrupt thread.

Workaround confirmed: switch to another/new thread before archiving the target thread, or unarchive via codex unarchive <session_id> if already stuck. The underlying archive state appears correct; the visible failure is the app continuing to route/resume the archived active conversation.

alibrohde · 1 month ago

I’m seeing this frequently on macOS as well.

Environment:

  • Codex Desktop app version: 26.527.60818
  • Bundled CLI: codex-cli 0.136.0-alpha.2
  • macOS: 15.6.1 arm64

Latest toast from the app:

Failed to resume chat
session 019e8898-9daa-7c50-8819-6ebabc66c910 is archived. Run `codex unarchive 019e8898-9daa-7c50-8819-6ebabc66c910` to unarchive it first.

This happens after archiving a chat from the Desktop UI. The archive appears to work, but the UI remains bound to the archived thread and tries to resume it.

harvitronix · 1 month ago

Seeing this as well. Then the remaining chat will sometimes show a message from the archived chat and it will blink in and out, as if caught in a re-render loop.

This happens upon clicking "confirm" when archiving a chat in the sidebar.

Edit:

  • Codex Desktop app version: 26.527.60818 (3437)
  • macOS: 26.5 (25F71)

<img width="1056" height="273" alt="Image" src="https://github.com/user-attachments/assets/d5119778-aa9c-452c-9f04-4c7e0b7ee321" />

chrishas35 · 1 month ago

Seeing this today as well. In my case its the keyboard shortcut to archive, but same result. Codex helpfully sent me here to search for existing issues :)

  • Codex Desktop Version 26.527.60818 (3437)
  • codex-cli 0.136.0 (via brew)
  • macOS
  • Launched via codex app and directly from dock.
natefineman · 1 month ago

Another macOS confirmation from Codex Desktop. This happens every time I archive/delete a chat from the app UI: the archive appears to succeed, then the app immediately shows the red Failed to resume chat toast for the same just-archived session.

Environment:

  • Codex Desktop: 26.601.20914 (3497)
  • Bundled app CLI: codex-cli 0.136.0-alpha.2
  • Default shell codex on PATH: codex-cli 0.133.0 (notably does not expose archive / unarchive, while the bundled app CLI does)
  • macOS: 26.5 (25F71)

Local checks after reproducing:

  • codex doctor reported the state DBs as healthy.
  • The thread referenced by the toast was correctly marked archived = 1 in ~/.codex/state_5.sqlite.
  • Its rollout file existed under ~/.codex/archived_sessions, so this did not look like storage corruption or a failed archive.
  • The app-local projectless-thread-ids list looked stale: 208 ids total, only 4 active, 149 archived, 55 missing. That may be unrelated, but it seems consistent with archived/missing sidebar entries still being treated as selectable/resumable UI state.

User-visible behavior: after archiving/deleting a chat, no extra action is taken, but the app still tries to resume that archived chat and shows the error. This makes normal chat cleanup noisy even though the underlying archive seems to have worked.

realZillionX · 1 month ago

same issue

sachah · 1 month ago

Another confirmation from Codex Desktop on macOS. This reproduces when archiving from the recent tasks menu: the archive succeeds, then the Desktop UI immediately tries to resume the same archived conversation and shows the red Failed to resume chat toast.

Environment:

  • Codex Desktop: 26.601.21317 (3511)
  • Bundled app CLI: codex-cli 0.136.0-alpha.2
  • PATH CLI: codex-cli 0.136.0
  • macOS: 26.5 (25F71) arm64

Two session ids observed in back-to-back reproductions:

  • 019e8bcf-303c-7932-b8cc-3260608f760c
  • 019e8bd1-ba84-76a0-9b8b-c588e2c5541c

Local state after reproducing:

  • Both sessions are correctly marked archived=1 in ~/.codex/state_5.sqlite.
  • Both rollout files exist under ~/.codex/archived_sessions:
  • rollout-2026-06-02T21-47-51-019e8bcf-303c-7932-b8cc-3260608f760c.jsonl
  • rollout-2026-06-02T21-50-38-019e8bd1-ba84-76a0-9b8b-c588e2c5541c.jsonl
  • codex doctor reports state DBs healthy, but also reports thread inventory warnings: rows pointing at missing/unusable archived rollout files. That may be unrelated, but the two reproduced sessions above had valid archived files and DB rows.

Relevant log sequence for 019e8bd1-ba84-76a0-9b8b-c588e2c5541c:

2026-06-03T04:50:45.126Z info [electron-message-handler] Archive requested conversationId=019e8bd1-ba84-76a0-9b8b-c588e2c5541c source=recent_tasks_menu
2026-06-03T04:50:45.212Z info [AppServerConnection] response_routed ... method=thread/archive ... errorCode=null
2026-06-03T04:50:45.300Z info [AppServerConnection] response_routed ... method=thread/read ... errorCode=null
2026-06-03T04:50:45.490Z info [AppServerConnection] response_routed ... method=thread/resume ... errorCode=-32600
2026-06-03T04:50:45.491Z error [electron-message-handler] Request failed conversationId=019e8bd1-ba84-76a0-9b8b-c588e2c5541c ... method=thread/resume ... "session 019e8bd1-ba84-76a0-9b8b-c588e2c5541c is archived. Run `codex unarchive 019e8bd1-ba84-76a0-9b8b-c588e2c5541c` to unarchive it first."
2026-06-03T04:50:45.509Z info [AppServerConnection] response_routed ... method=thread/goal/get ... errorCode=-32600
2026-06-03T04:50:45.510Z error [electron-message-handler] Request failed conversationId=019e8bd1-ba84-76a0-9b8b-c588e2c5541c ... method=thread/goal/get ... "thread not found: 019e8bd1-ba84-76a0-9b8b-c588e2c5541c"

Same pattern for 019e8bcf-303c-7932-b8cc-3260608f760c: archive requested from recent_tasks_menu, then repeated method=thread/resume failures for the same archived conversation id.

This looks like the archive action is correct, but the mounted Desktop route/view continues to hydrate/resume the just-archived active conversation instead of navigating away or clearing the active conversation.

alibrohde · 1 month ago

Adding another macOS repro with the same active-thread-after-archive state bug.

Environment:

  • macOS 15.6.1, arm64
  • Codex Desktop bundled CLI: codex-cli 0.136.0-alpha.2
  • Local/project chat in Codex Desktop

Observed flow:

  1. Archive the currently open thread from the Desktop UI.
  2. The archive appears to succeed, but the main pane stays on that same thread instead of navigating away.
  3. The app then shows:
Failed to resume chat
session 019e8ac5-6571-7083-9d2a-5517e9fbbcc7 is archived. Run `codex unarchive 019e8ac5-6571-7083-9d2a-5517e9fbbcc7` to unarchive it first.
  1. If I then try to start fresh in that same window, it still appears bound to the archived session and shows:
Error creating task
session 019e8ac5-6571-7083-9d2a-5517e9fbbcc7 is archived. Run `codex unarchive 019e8ac5-6571-7083-9d2a-5517e9fbbcc7` to unarchive it first.

Expected behavior: after archiving the active thread, Desktop should shut down/clear that active thread route and navigate to a net-new thread/new-chat state, or to another non-archived thread. It should not leave the archived thread as the target for resume or new task creation.

kenfast007 · 1 month ago

Check whether your iCloud storage is full: Codex reads your Non-project session from ~/Documents/Codex. If sessions from other devices have not been downloaded locally, that error may occur.