Codex Desktop: archived automation threads remain visible in sidebar #23246

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   automations

   on May 18, 2026
2. ei060 commented on Sep 12, 2026

   

   ei060

   on Sep 12, 2026 – with ChatGPT Codex Connector

   Last edited by ei060

   More actions

   Additional reproduction on Windows with local recurring automation tasks.

   Completed automation runs were archived using the native Codex task-management tool, but many entries remain in the project sidebar.

   For one exact affected task, we verified:

   • The persisted thread state reports archived=1.
   • The native archived-task listing includes the same task.
   • Clicking its sidebar entry displays “This task is archived” and an “Unarchive and open” button.
   • Collapsing and expanding the project did not remove the entries.
   • The user reports that exiting and reopening the application also did not resolve the issue.

   Expected: archived tasks remain recoverable through Archived tasks but disappear from the active project sidebar.

   This case uses local Windows tasks, not SSH tasks. No database/index edits, task deletion, or automation configuration changes were performed during this cleanup.

   Desktop About version: 26.908.40834.
   Release date shown in About: September 12, 2026.
   App branding: ChatGPT — Powered by Codex & OWL.

   The root cause is unconfirmed; the evidence establishes a mismatch between archive state and sidebar visibility.

   Task IDs, project names, local paths, account details, and conversation contents are intentionally omitted.

   Follow-up: native re-archive removes inspected catalog rows, but the sidebar remains unchanged

   We tested reapplying archived=true through the native Codex App task-management tool, without first unarchiving the tasks.

   • For an exact affected sample, a read-only before/after check showed that its local_thread_catalog entry was removed while its archived flag and original archive timestamp remained unchanged.
   • We then restricted the same operation to previously reviewed, already-archived historical runs that still had catalog entries. Immediately before each operation, we rechecked that the task was completed, still archived, and not pinned.
   • A subsequent read-only check found no remaining local_thread_catalog entries for the previously archived set; their archived flags remained set.
   • Nevertheless, the user reported that the project sidebar looked unchanged, both immediately afterward and after another normal application exit and relaunch.

   The post-relaunch observation is user-reported visual evidence, not a fresh post-relaunch database snapshot. We have not established whether entries were recreated during startup or whether the visible sidebar uses another source. Clearing the inspected catalog rows therefore did not establish a successful UI repair.

   All mutations in this test used the native archive tool. No direct database/index edits, permanent deletion, automation configuration changes, or unarchive operations were performed.

   Could maintainers provide a supported diagnostic method for identifying the actual sidebar data source and archive reconciliation path in desktop version 26.908.40834? No root cause is claimed. No raw databases, logs, screenshots, task identifiers, private paths, or conversation contents are attached.
3. hnurewnik-hash commented on Sep 21, 2026

   

   hnurewnik-hash

   on Sep 21, 2026

   More actions

   Additional macOS reproduction for the same issue (ChatGPT desktop app version 26.915.31945, local project with recurring Codex automations).

   Four scheduled automations create separate run threads. We archived completed and failed run histories through the native Codex task-management tool. A full archived-task listing contains 52 run histories for these four automation titles. The active-task listing contains no unarchived threads with those titles. Nevertheless, the local project sidebar still displays repeated rows for the archived runs (roughly nine visible at once). The rows remain after quitting and reopening the desktop app.

   We also retried archive=true on an archived sample, unarchived and re-archived one archived sample, and moved the project to Pinned and back. None resolved the visible duplicates. No direct database or index edits were made. The schedules remain active.

   Possible diagnostic lead, not a claimed root cause: local project assignment state still references archived run IDs, while thread assignment migration state reports 49 pending IDs and threadAssignmentsMigrated=false. The archived-task API returns these threads as archived, not active. It appears that the project sidebar is using or retaining membership that is not reconciled with archive state.

   Expected: archived run threads remain recoverable in the archive but disappear from the active project sidebar. Please advise on a supported reconciliation or repair path. I am omitting private paths, task IDs, raw logs, screenshots, and conversation content.