Skip to content

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

Open
Open
Codex Desktop macOS: archiving the currently viewed chat leaves right pane on archived thread and triggers session is archived#25769
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@29988122
29988122
opened on Jun 2, 2026

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jun 2, 2026

  2. github-actions commented on Jun 2, 2026

    @github-actions
    github-actionsbot
    on Jun 2, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. alibrohde commented on Jun 2, 2026

    @alibrohde
    alibrohde
    on Jun 2, 2026

    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.

  5. harvitronix commented on Jun 2, 2026

    @harvitronix
    harvitronix
    on Jun 2, 2026

    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)
    Image

  6. chrishas35 commented on Jun 2, 2026

    @chrishas35
    chrishas35
    on Jun 2, 2026

    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.

  7. natefineman commented on Jun 2, 2026

    @natefineman
    natefineman
    on Jun 2, 2026

    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.

  8. sachah commented on Jun 3, 2026

    @sachah
    sachah
    on Jun 3, 2026

    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.

  9. alibrohde commented on Jun 3, 2026

    @alibrohde
    alibrohde
    on Jun 3, 2026

    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.

  10. kenfast007 commented on Jun 4, 2026

    @kenfast007
    kenfast007
    on Jun 4, 2026

    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.

  11. dsfaccini commented on Jul 22, 2026

    @dsfaccini
    dsfaccini
    on Jul 22, 2026

    This comment was posted by Codex Desktop using gpt-5.6-terra on behalf of David.

    This affects us as well, through a slightly different navigation path. After archiving a recently used thread, Ctrl+Tab still cycles to that archived thread as part of the recent-thread history, even though the thread is no longer shown in the visible UI for the task switcher. If navigation stops on it, Codex shows a "conversation not found" error.

    Expected: archived threads should be removed from the Ctrl+Tab/recent-thread navigation list as soon as archival succeeds, rather than only being hidden from its UI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions