Skip to content

[macOS][Desktop][multi-host] Sidebar grouping resets and archived tasks resurrect after restart #41214

Open
Open
[macOS][Desktop][multi-host] Sidebar grouping resets and archived tasks resurrect after restart#41214
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@alexander-dreyzen
alexander-dreyzen
opened on Aug 27, 2026

What version of the Codex App are you using?

  • Unified ChatGPT/Codex Desktop for macOS: 26.820.60940
  • Bundle build: 7119
  • Subscription: paid ChatGPT subscription (exact tier omitted)

What platform and connection topology are you using?

  • macOS 26.5.2 (25F84), Apple silicon
  • Three macOS development hosts connected to one Desktop client
  • Tasks are available through the local host plus SSH-discovered and Remote Control projections
  • All supported connection paths are enabled simultaneously

This multi-host topology may be important. The failure is most visible when the sidebar must reconcile tasks from several physical hosts and more than one projection type.

What issue are you seeing?

The Codex Desktop left sidebar does not preserve or deterministically reconstruct its task-list state across a full quit/restart or an app update.

The Recents task view supports:

  • grouping by Project;
  • grouping by Connection;
  • one combined list; and
  • ordering such as Priority or Latest Updated.

My preferred configuration is group by Project and Latest Updated. That configuration and the resulting task organization are reliable only within the current app session.

After quitting and restarting Codex—or after an app update—the sidebar can rehydrate into a different and internally inconsistent state:

  1. Tasks that were grouped under their projects move into Recents as apparently projectless items.
  2. Only a subset may be misplaced; which tasks move is non-deterministic.
  3. Group by Connection is also inconsistent: task placement does not reliably correspond to the physical host or connection projection, and the resulting buckets can appear arbitrary.
  4. Tasks that were archived, or deleted/removed through the available UI, can reappear in the active sidebar after restart.
  5. Re-archiving a resurrected task removes it from the current active list, but opening Archived tasks can still show an empty list.
  6. A later restart can resurrect tasks again, requiring the same manual cleanup.

The result is that active, archived, project-grouped, projectless, and connection-grouped views appear to be reading or hydrating from different state owners.

Steps to reproduce

The exact subset of affected tasks varies, but the overall failure is repeatable.

  1. Connect Codex Desktop to several existing development hosts through all available connection methods, including SSH discovery and Remote Control.
  2. Have multiple tasks across several saved projects and hosts.
  3. In the sidebar, select:
    • Group by Project
    • Latest Updated
  4. Confirm that tasks appear under the intended projects.
  5. Archive several obsolete tasks. If deletion/removal is available for a task, remove one as well.
  6. Confirm that those tasks disappear from the active list.
  7. Fully quit Codex Desktop.
  8. Relaunch the app, or install an update and relaunch.
  9. Inspect the sidebar:
    • some formerly project-grouped tasks may now appear under Recents;
    • Group by Connection may place tasks inconsistently;
    • archived or removed tasks may have reappeared as active.
  10. Archive a resurrected task again.
  11. Open the Archived tasks view.
  12. Observe that the active row disappears, but the Archived view may be empty.
  13. Restart again and observe that stale tasks may reappear.

Expected behavior

  • The selected grouping and sorting preferences survive restart and app updates.
  • A task has one canonical identity even when it has local, SSH-discovered, or Remote Control projections.
  • Project grouping is derived from one durable, authoritative project assignment.
  • Connection grouping consistently represents the task's actual physical host and selected projection.
  • Archive and deletion tombstones are durable and take precedence over stale catalog or remote projection data.
  • An archived task appears in Archived tasks and remains absent from active lists after restart.
  • A deleted task never reappears.
  • Startup hydration converges to the same result every time for unchanged underlying state.

Actual impact

Impact: high.

This is not cosmetic. The sidebar is the primary navigation and continuity surface for long-running Codex work. Restarting the app can destroy carefully curated project organization, make dead work look active again, and make archive/delete actions impossible to trust. With many projects and tasks across three hosts, manually reclassifying and re-archiving items after every restart is expensive and error-prone.

The inconsistent empty Archived view also prevents users from determining whether an archive action persisted or only changed the current renderer state.

Possible root-cause family

This is an inference from the visible behavior, not a confirmed diagnosis.

Startup/update hydration may be merging several catalogs or projections without one authoritative precedence order:

  • saved Desktop project assignments;
  • task-list/project projections;
  • local and remote host catalogs;
  • SSH-discovered and Remote Control projections;
  • active task rows;
  • archive/delete tombstones; and
  • persisted sidebar grouping preferences.

A stale projection may be able to recreate an active row after a newer archive/delete state, while the Archived view reads a different or incomplete catalog. Project and connection grouping may likewise consume inconsistent identifiers.

Related reports, but not duplicates

This report combines behavior not covered by any one of those issues: persistent view-mode loss, project and connection misgrouping, and archive/delete resurrection in a three-host SSH/Remote Control topology.

Privacy

Task IDs, project names, sidebar titles, account identifiers, absolute paths, and private task contents are intentionally omitted. Sanitized task/host coordinates or logs can be provided privately if maintainers identify the relevant diagnostic surface.

Activity

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

  2. github-actions commented on Aug 27, 2026

    @github-actions
    github-actionsbot
    on Aug 27, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. usafancyei commented on Aug 29, 2026

    @usafancyei
    usafancyei
    on Aug 29, 2026

    I can reproduce the archived-task resurrection/hydration problem on a single-host, local-only setup, so this does not appear to require SSH or Remote Control projections.

    Environment:

    • ChatGPT/Codex Desktop for macOS: 26.825.41651
    • Bundle build: 7345
    • Bundled CLI: 0.151.0-alpha.7.1
    • Apple silicon
    • One local host only

    Observed evidence:

    • During one affected session, the Desktop UI attempted to hydrate 21 already-archived local tasks across two local workspaces.
    • The app logs show thread/read followed by thread/resume, which fails with error code -32600: session is archived.
    • The same events are tagged with failureReason=thread_archived, source=thread_hydration, and "Failed to load older thread history".
    • A thread/list refresh follows each failure, but the stale task remains discoverable in the UI.
    • The state database correctly reports archived=1.
    • The rollout files exist only under archived_sessions, not sessions.
    • The normal active-task list and archived-task list have no ID overlap.
    • codex doctor reports healthy state databases and zero archive-state mismatches. It also reports four unrelated inventory warnings whose IDs do not overlap the affected tasks.
    • The problem reproduced both before and after updating from desktop release 26.825.32147 to 26.825.41651.

    This appears to extend #41214 beyond the reported multi-host topology and overlaps with the stale active-route/hydration behavior in #25769.

    A client-side fix likely needs to:

    1. Evict a task from every sidebar/history pagination cache after thread/archived.
    2. Treat archive tombstones as authoritative during startup hydration.
    3. Remove the row and leave the route when thread/resume returns thread_archived.
    4. Ensure older-history queries explicitly exclude archived tasks.

    No task IDs, project names, absolute paths, account identifiers, or private task contents are included here.

  4. mrwillystudio commented on Aug 30, 2026

    @mrwillystudio
    mrwillystudio
    on Aug 30, 2026

    Confirmed on Windows Desktop with local Git worktrees. After the worktree paths became unavailable, two stale worktree tasks remained under the project sidebar. Git worktree metadata was removed and both tasks were archived through the app API, but they still appeared after a full Desktop restart. The sidebar actions were unavailable, so the stale rows could not be removed or archived from the UI. Only the current task should remain.

  5. Turtle-Hwan commented on Aug 31, 2026

    @Turtle-Hwan
    Turtle-Hwan
    on Aug 31, 2026

    Cross-platform confirmation: this is reproducible on both the current macOS and Windows Desktop releases, particularly with SSH-connected tasks.

    Environment

    • macOS Desktop: 26.825.51511 (build 7377)
    • Bundled Codex CLI on macOS: 0.151.0-alpha.7.2
    • macOS platform: Darwin 25.5.0 arm64
    • Windows Desktop: latest release offered through the normal update channel immediately before reproduction (exact About version was not captured for this report)
    • Topology: Codex Desktop connected to remote development tasks over SSH

    Hostnames, network addresses, usernames, project names, task titles, and task IDs have been intentionally omitted.

    Cross-platform observed behavior

    The same lifecycle failure occurs on both Windows and macOS Desktop:

    1. A task is archived on its remote/owner host.
    2. The authoritative remote state reports the task as archived.
    3. The Desktop active sidebar continues to display the archived task.
    4. Clicking the stale row triggers a resume attempt and displays session <redacted-session-id> is archived.
    5. The row may disappear only after the failed resume attempt.
    6. After a later refresh, reconnection, or restart, archived tasks can reappear in the active sidebar.

    For an inspected reproduction, the owner-host state was internally consistent:

    • the state database reported archived=1;
    • the rollout existed under the generic archived_sessions location;
    • the active and archived owner-host state did not overlap;
    • the stale active entry existed only in the Desktop sidebar/navigation state.

    This indicates that the archive mutation itself succeeds. The failure is in Desktop lifecycle invalidation, sidebar reconciliation, or route hydration.

    User impact

    This is recurring frequently enough to make normal sidebar use and task cleanup frustrating. Tasks that were deliberately archived keep coming back into the active list, so the sidebar is repeatedly cluttered with work that should no longer require attention.

    There is also no reliable visual way to distinguish a real active task from one of these stale archived entries. I have to click each stale entry, wait for the session is archived error, and let it disappear individually. The same cleanup may need to be repeated after reconnecting or restarting the app.

    As a result, archive cannot currently be trusted as a durable organization action. It adds repeated manual cleanup, interrupts navigation between actual active tasks, and makes it difficult to know whether a task genuinely returned or the sidebar is showing stale state.

    Related issue chain

    This appears to connect the following reports into one end-to-end failure:

    The observed sequence is:

    archive succeeds on owner host -> Desktop misses lifecycle invalidation -> stale sidebar/history entry remains or is rehydrated -> Desktop calls thread/resume -> owner host correctly returns thread_archived

    Because the same behavior occurs on both current Windows and macOS releases, this is unlikely to be limited to one OS-specific storage implementation. It more likely affects shared Desktop sidebar/reconciliation logic or the cross-host lifecycle event path.

    A robust client-side fix likely needs to:

    1. Treat the owner host's archive tombstone as authoritative.
    2. Invalidate every projection keyed by both host and conversation identity.
    3. Remove archived tasks from sidebar, recent-navigation, and active-route caches.
    4. Evict stale rows when thread/resume returns thread_archived.
    5. Reconcile archive state during startup and SSH reconnection.

    No raw logs or state files are attached because they may contain sensitive paths, task contents, or identifiers.

  6. hanjie-chen commented on Sep 5, 2026

    @hanjie-chen
    hanjie-chen
    on Sep 5, 2026

    Additional confirmation on Windows Desktop with an SSH-connected Linux ARM64 host, plus a narrow recovery that removed the stale persistent catalog entry.

    Environment: Microsoft Store package OpenAI.Codex 26.901.4073.0 (unified ChatGPT/Codex Desktop). One affected SSH task was inspected on 2026-09-05.

    Observed evidence:

    • The owner-host state_5.sqlite row remained archived=1, with the original archive timestamp unchanged since 2026-08-24. The rollout existed only under archived_sessions.
    • The normal active-task list excluded the task and the archived-task list included it.
    • The Windows Desktop codex-dev.db / local_thread_catalog nevertheless contained the same (host_id, thread_id), with host_kind=ssh and missing_candidate=0.
    • On multiple app launches, clicking the resurrected row caused thread/resume to return -32600, failureReason=thread_archived, source=thread_hydration. The row then disappeared for the current app session, but the persistent catalog entry remained.
    • The SSH catalog had initial_build_complete=1 and a completed full-reconciliation timestamp after the original archive date, while the stale row was still present.

    Recovery experiment:

    1. Backed up the Desktop catalog database and the exact affected row.

    2. Used the built-in Codex app task tool to set archived=true again for that exact task and SSH host. No unarchive step or direct database edit was performed.

    3. Verified that the stale local_thread_catalog row count changed from 1 to 0.

    4. Verified that the owner-host archived flag, original archive timestamp, and archived rollout remained intact. Desktop database quick_check returned ok.

    5. After the recovery, the user restarted the Desktop app and reported that the previously archived task no longer reappeared in the sidebar.

    The recovery therefore held across one user-verified restart for this affected task. Repeated restarts and other tasks have not been tested, so this is evidence for a working recovery in this case rather than a permanent product fix.

    This appears to match the SSH archive/resume lifecycle described above and adds evidence that reapplying archive through the Desktop app can repair the persistent catalog entry even when owner-host archive state was already correct. Startup reconciliation and the thread_archived error path should converge to that same durable removal without requiring manual re-archiving.

    No task IDs, hostnames, project names, screenshots, private paths, raw logs, or conversation content are included.

  7. Xarth-Mai commented on Sep 11, 2026

    @Xarth-Mai
    Xarth-Mai
    on Sep 11, 2026 – with ChatGPT Codex Connector

    Additional Linux reproduction of the external-archive/sidebar resurrection behavior, matching the sequence described in earlier comments.

    Environment: Linux desktop; installed ChatGPT/Codex package metadata reports version 26.903.71938 (prod, ChatGPT branding). Observed on 2026-09-12.

    My recurring workflow and observed behavior:

    1. A Codex task is visible in the desktop sidebar.
    2. I archive it outside that desktop window, for example through CLI usage or while accessing the development environment over SSH from my phone.
    3. The desktop sidebar still lists the task as if it were active.
    4. Clicking the entry makes the desktop recognize that it is archived and immediately remove it from the visible list.
    5. On the next desktop launch, the same entry reappears. I have to archive it again from the desktop.

    Step 4 is particularly misleading: the temporary disappearance looks like successful reconciliation, but it does not survive restart. This is a user-observed reproduction; I have not captured an owner-host database snapshot or protocol trace for this archive scenario, so I cannot confirm which persistence or synchronization layer is responsible.

    Expected: once the desktop learns that a task is archived, that state should consistently exclude it from the active sidebar after restart, without another archive action. Please include external CLI/SSH archiving followed by open, dismissal, and restart in regression coverage.

    I am also reporting the separate deleted-ChatGPT-chat case in #42236; similar symptoms do not establish a shared root cause.

  8. Nuriko93 commented on Sep 23, 2026

    @Nuriko93
    Nuriko93
    on Sep 23, 2026

    Title: Remote SSH archived tasks reappear in Desktop sidebar after every restart
    Environment

    • ChatGPT/Codex Desktop on Windows
    • Remote SSH connection to Linux host
    • Codex CLI on remote host
    • ChatGPT subscription authentication
      Issue
      Archived Remote SSH tasks repeatedly reappear in the active Desktop sidebar after restarting the ChatGPT/Codex app.
      The archive state on the remote host is correct. In Codex CLI, only the actually active task is shown. The remote SQLite state also marks the affected threads as archived.
      However, after restarting the Desktop app, multiple archived Remote SSH tasks appear again in the normal project/sidebar list as if they were active.
      If I click one of these resurrected tasks, the app itself displays:
      “This task is archived — Unarchive this task to open it.”
      After opening/clicking the task, it disappears from the active sidebar again without me unarchiving it.
      After the next app restart, the same archived tasks reappear again.
      Steps to reproduce
    1. Connect Codex Desktop to a Linux host using Remote SSH.
    2. Archive several remote tasks.
    3. Confirm in Codex CLI that they are archived and no longer listed under Active.
    4. Quit the Desktop app completely.
    5. Reopen the app.
    6. Observe that archived Remote SSH tasks are shown again in the active sidebar.
    7. Click one of them.
    8. The app says “This task is archived”.
    9. The sidebar entry disappears.
    10. Restart the app again.
    11. The same archived task reappears.
      Expected behavior
      Archived Remote SSH tasks should remain absent from the active sidebar across restarts and updates.
      Actual behavior
      The Desktop sidebar appears to rehydrate stale Remote SSH task entries on startup without respecting the canonical archived state.
      Additional evidence
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 workingremotesessionIssues 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