›_ Codex Issues
Codex Issues / #14162

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

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

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.305.950 (863)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

Codex desktop is showing stale/orphaned thread entries that cannot be reopened or archived. For thread IDs 019ccff2-7936-74e2-b59d-f678c2860b10 and 019ccf94-8e1d-72b2-a061-72bc1db23b15, the UI still surfaces them, but the local thread store has no matching rollout/thread record. For 019ccff2-7936-74e2-b59d-f678c2860b10, the app log shows thread/resume failing with no rollout found for thread id ....

Submitted feedback with: 019cd5bf-c102-7612-9f3a-2ea899da81f8

What steps can reproduce the bug?

Repro is not fully deterministic yet, but the broken state is reproducible once a stale/orphaned thread entry exists in the desktop UI.

Observed repro path:

  1. Open Codex desktop and navigate to a thread entry that is still shown in the sidebar/list.
  2. Click the thread to reopen it.
  3. Codex attempts thread/resume, but the backing rollout/thread metadata is missing locally.
  4. The thread cannot be opened, and it also cannot be archived/cleaned up from the UI.

Observed error:
no rollout found for thread id <thread_id>

What is the expected behavior?

If a thread no longer has backing metadata, Codex should either hide it automatically or provide a working cleanup/remove/archive path instead of leaving a broken UI entry.

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

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

  • #14137
  • #12955
  • #13582
  • #13846

Powered by Codex Action

etraut-openai contributor · 4 months ago

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.

cheulyop · 4 months ago

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.

etraut-openai contributor · 4 months ago

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.

agustif · 4 months ago
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?

michaelpearce90 · 3 months ago

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.

klawdius-noodle · 3 months ago

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.