Codex desktop is showing stale/orphaned thread entries that cannot be reopened or archived. #14162

Activity

1. cheulyop

   added

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

   on Mar 10, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   on Mar 10, 2026
3. github-actions commented on Mar 10, 2026

   

   github-actionsBot

   on Mar 10, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Bug: app-server can retain orphaned threads after last-subscriber disconnect #14137
   • Codex stale-thinking spinner persists after stream state desync (thread stale detection + targeted recovery results) #12955
   • Ephrmale thread when starting a worktree #13582
   • Windows app: threads disappear after restart when project is on a mapped network drive (possible //?/unc/... path normalization issue) #13846

   Powered by Codex Action
4. etraut-openai commented on Mar 10, 2026

   

   etraut-openai

   on Mar 10, 2026

   Contributor

   More actions

   By any chance, did you manually delete the rollout files for these threads? Codex maintains a sqlite db for fast lookup of thread metadata and enumeration. It sounds like it may be out of sync with the rollout files.
5. cheulyop commented on Mar 10, 2026

   

   cheulyop

   on Mar 10, 2026

   Author

   More actions

   Yes, I frequently request codex to find stale worktrees/branches and prune them and I saw Codex reading sqlite db. It seems likely that some files were deleted in the process.
6. etraut-openai commented on Mar 10, 2026

   

   etraut-openai

   on Mar 10, 2026

   Contributor

   More actions

   Yeah, that would explain it. Try renaming the sqlite db (~/.codex/sqlite/codex-dev.db), then relaunch Codex. It should rebuild the db based on the on-disk rollouts that it finds.

   👍React with 👍1Reacted by Cheul
7. agustif commented on Mar 10, 2026

   

   agustif

   on Mar 10, 2026

   More actions

   By any chance, did you manually delete the rollout files for these threads? Codex maintains a sqlite db for fast lookup of thread metadata and enumeration. It sounds like it may be out of sync with the rollout files.

   I usually tell codex to manage worktrees via cli itself and spawn sub-agents assigning them a worktree/branch pair, could this be why im hitting my related bug?
8. michaelpearce90 commented on Mar 26, 2026

   

   michaelpearce90

   on Mar 26, 2026

   More actions

   I hit what looks like the same underlying thread/rollout failure on Windows 11 with a WSL-opened repo.

   Observed error:
   no rollout found for thread

   My additional context:
   • this happened while creating/running an automation in a WSL-opened Git repo
   • normal local threads worked and returned the correct cwd
   • the failing automation/thread path flashed the error and did not recover
   • session ID from in-app feedback: 13cb61d3-2d73-46b4-9120-19248ea0665d

   I originally filed this separately, but my issue was closed as overlapping with existing reports, so adding this here as another Windows + WSL datapoint.
9. klawdius-noodle commented on Apr 3, 2026

   

   klawdius-noodle

   on Apr 3, 2026

   Last edited by klawdius-noodle

   More actions

   I can reproduce a closely related failure on Windows + WSL in the Codex desktop app, specifically with Automations.

   Current behavior on my machine:

   • Creating/running an automation fails with:
   • • Failed to resume thread
   • • • no rollout found for thread id 019d559f-78e8-72c0-8e00-949fdae17bb4
   • • • • This is not just a stale old thread in the sidebar. The failing thread id is created as part of the automation run path.
   • • • • • After the failure, the same dead thread id keeps getting retried.
             Local evidence:
   • ~/.codex/sqlite/codex-dev.db gets an automation_runs row for that thread id with status IN_PROGRESS.
   • • ~/.codex/state_5.sqlite has no matching row in threads for that same id.
   • • • ~/.codex/sessions/... has no rollout file for that exact thread id.
   • • • • So the automation run bookkeeping is persisted, but the backing resumable thread/rollout is never persisted.
           Extra notes:
   • I am on the latest Codex desktop build as of 2026-04-04.
   • • WSL prerequisites do exist on this machine: the automation cwd exists, the python3, node, git, and bash are present in WSL.
   • • • Deleting the orphaned automation_runs row alone did not fix it permanently. The app still tried to reopen the same dead thread from cached state.
         This looks like the same underlying orphaned-thread / missing-rollout class, but via Automations on Windows+WSL rather than only normal thread resume.
10. ambrosino-oai

    self-assigned this

    on Jul 2, 2026
11. ambrosino-oai

    closed this as completedon Jul 2, 2026
12. linear

    reopened this on Jul 16, 2026
13. linear

    assigned

    gpeal

    and unassigned

    ambrosino-oai

    on Jul 16, 2026
14. moodysalem commented on Sep 10, 2026

    

    moodysalem

    on Sep 10, 2026

    More actions

    Additional evidence for the same orphaned-entry failure on Linux with CLI/TUI and persistent app-server 0.154.0:

    An empty ordinary session was started and then shut down without ever running a turn. The overview retained its row. codex archive <id> returned only Error: failed to archive session; the underlying thread/archive response was -32600: no rollout found for thread id <id>. thread/read returned thread not loaded. Read-only inspection confirmed no state row, rollout, turn history, or pending input for that empty session. Lifecycle logs showed the empty session's start and idle shutdown.

    The source appears to explain the combination:

    • RolloutRecorder::new defers file creation until persistence.
    • track_agents_overview_notification retains overview membership: ThreadClosed changes status to NotLoaded, while only ThreadArchived/ThreadDeleted removes the row. Failed metadata reads log a warning without evicting the stale membership.
    • archive_thread_with_paths requires resolve_current to return a rollout, so archiving cannot produce the notification that would remove this row.

    Suggested regression case: start a non-ephemeral empty thread while another TUI observes the overview; close/unload it before the first persisted user turn; then archive its retained overview entry. The UI should provide a working cleanup path for a confirmed non-persisted closed session, without treating ordinary transient read failures as permission to remove valid sessions.

    No private session identifiers, paths, prompts, or raw logs are included here.
15. thnk2wn commented on Sep 11, 2026

    

    thnk2wn

    on Sep 11, 2026

    Last edited by thnk2wn

    More actions

    Adding a macOS reproduction with a known deletion path:

    • ChatGPT/Codex desktop: 26.908.40834
    • Codex CLI used for deletion: 0.153.4

    Observed sequence

    1. Leave the desktop app running with existing local tasks visible in a project sidebar.

    2. Delete specific saved tasks using the supported CLI command:

       codex delete --force <task-uuid>

    3. The CLI reports Deleted session <task-uuid>.

    4. Read-only checks confirm the deleted task IDs are absent from the threads table in state_5.sqlite and their recorded rollout files are gone. The set of removed top-level IDs matches exactly the requested deletions; other task records remain.

    5. Desktop still displays the deleted tasks in the project sidebar.

    6. Clicking one of the stale rows displays:

       Failed to resume chat
       no rollout found for thread id <task-uuid>
       

    The missing rollout is expected after successful deletion. The problem is that desktop continues presenting the deleted task as available to open.

    Unlike the earlier manually deleted rollout-file scenario discussed above, these deletions were performed with codex delete, and both the task record and rollout were removed. No manual database mutation or rollout-file deletion was used.

    Expected behavior

    The desktop task list should reconcile deletions made through the supported CLI and remove the stale rows. If a user clicks an entry already confirmed deleted, the app should refresh/remove it and explain that it was deleted rather than repeatedly attempting to resume a nonexistent rollout.

    Confirmed: fully quitting and relaunching the desktop app did not clear the stale sidebar entries. They remain visible after a full restart. The internal persistence/cache/notification cause is not established.

    No screenshots, task titles, real task IDs, project names, account details, or raw logs are included.