Missing rollout leaves an unarchivable ghost thread in the Windows sidebar

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

Bug: Missing rollout leaves an unarchivable “ghost” thread in the Windows sidebar

Summary

On the Codex/ChatGPT Windows desktop app, a local thread remained visible in the sidebar and repeatedly failed to archive because its rollout file was missing while the state database still retained the thread row and stale rollout path. The item survived full app restarts and was also treated as a pinned thread by the renderer even after the backend could no longer load it.

The UI eventually reported archive success only after the stale local state was cleaned up and an explicit unpin operation was sent. The app should self-heal this state without requiring manual SQLite/session cleanup.

Environment

  • Platform: Windows 10 Home China 22H2, build 19045.6466, x64
  • Desktop app release reported in logs: 26.814.41957
  • App server version: 0.148.0-alpha.15
  • Selected Codex runtime bundle: 26.819.11345
  • Date observed: 2026-08-20
  • Thread title: 11
  • Thread ID: 01a01437-8518-78d2-8485-d0512fcbc1c5
  • Deep link: codex://threads/01a01437-8518-78d2-8485-d0512fcbc1c5

Preconditions inferred from logs and local state

  1. state_5.sqlite retained a row for the thread.
  2. Its rollout_path pointed to a JSONL file that no longer existed.
  3. The renderer/sidebar still retained the thread in its pinned/recent state.

The stale path was equivalent to:

%USERPROFILE%\.codex\sessions\2026\08\18\rollout-...-01a01437-8518-78d2-8485-d0512fcbc1c5.jsonl

Steps to reproduce

The original cause of the missing rollout is unknown, but the broken state can be described as follows:

  1. Have a local thread row in state_5.sqlite whose rollout_path no longer exists.
  2. Keep that thread visible or pinned in the sidebar.
  3. Restart the desktop app.
  4. Try Archive from the thread overflow menu, sidebar context menu, or Recent tasks menu.

Actual behavior

  • The app repeatedly shows archive failure.
  • Restarting does not remove the sidebar item.
  • The stale thread can remain visible even though thread/read and turn/start report that the thread is missing/not loaded.
  • Archive may fail through two related paths:
  • internal OS error because the rollout file is missing;
  • no rollout found, followed by failure to persist the inactive-thread archive.
  • The renderer can continue trying to hydrate the item as a pinned thread.

Expected behavior

If a thread's rollout is missing but a state-database/sidebar record remains, Archive should still remove the item from active and pinned sidebar state. The app should transactionally reconcile or quarantine the stale database row, clear its pinned state, invalidate the renderer cache, and optionally surface a recoverability warning. It should not require the missing rollout file merely to hide/archive the sidebar entry.

Sanitized log evidence

Archive requested ... method=thread/archive
errorCode=-32603
failed to archive session: thread-store internal error: failed to archive thread:
The system cannot find the file specified. (os error 2)

Archive skipped because thread has no active rollout
errorMessage="no rollout found for thread id 01a01437-8518-78d2-8485-d0512fcbc1c5"

Failed to persist inactive thread archive
errorMessage="Inactive thread archive did not persist"

state db list_threads returned stale rollout path for thread
01a01437-8518-78d2-8485-d0512fcbc1c5
state db discrepancy during list_threads_db: stale_db_path_retained

thread/read ... errorCode=-32600
message="thread not loaded: 01a01437-8518-78d2-8485-d0512fcbc1c5"

Failed to read pinned thread
threadId=01a01437-8518-78d2-8485-d0512fcbc1c5

Recovery that ultimately worked

The user observed successful archiving only after all of the following stale state had been reconciled:

  1. removed the stale thread row and exact-ID references from local structured state;
  2. confirmed the missing rollout/session file had no remaining live index entry;
  3. explicitly set the thread's pinned state to false;
  4. retried Archive in the desktop app.

Suggested fix

When thread/archive encounters rollout_not_found or OS error 2:

  1. fall back to a state-database-only archive transaction;
  2. clear is_pinned and any renderer-side pinned ID for the thread;
  3. invalidate the sidebar query/cache;
  4. remove or quarantine stale rollout_path entries;
  5. return success if the thread is no longer present in active sidebar state.

This would prevent a permanently visible “ghost” thread and avoid requiring users to edit local databases manually.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 8 days ago

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

  • #39182

Powered by Codex Action

80772673-sudo · 7 days ago

Additional reproduction from the same day, with a different failure variant:

Environment

  • Windows 11 x64, zh-CN
  • Codex Desktop package: OpenAI.Codex 26.818.2441.0
  • Codex CLI: 0.148.0-alpha.21
  • Observed: 2026-08-20, Asia/Shanghai (UTC+8)

Important difference

For this affected thread, the rollout JSONL file exists and is readable. The thread is also present in session_index.jsonl, and codex doctor --summary reports that the state database is healthy and the rollout/thread inventories agree.

Despite that, all archive paths fail:

thread/archive
errorCode=-32600
failureReason=rollout_not_found
message="no rollout found for thread id ..."

The CLI reports:

failed to archive thread: The system cannot find the file specified. (os error 2)

Recovery attempts

  1. Restarted Codex Desktop twice.
  2. Verified the rollout file and session-index entry.
  3. Ran a targeted dry-run:

codex migrate-rollouts --thread <redacted-thread-id> --json --verbose

  • Result: eligible
  1. Ran the same targeted migration with --apply.
  • Result: migrated
  • Approximately 1.1 MB processed.
  1. Restarted the desktop app again.

After migration, the task became readable/idle, but Archive still fails with OS error 2. No conversations were deleted; backups were made before migration.

A second completed task also intermittently appears as notLoaded after restart. This may indicate that the archive path resolver is using a stale or differently normalized rollout path even when the file and catalog entry both exist.

Please consider handling rollout_not_found/OS error 2 by reconciling the state DB, session index, and resolved rollout path before failing the archive operation. I can provide a focused sanitized log excerpt and screenshot if needed.