Codex Desktop can freeze when pinned/sidebar restore hits stale or oversized local rollout

Open 💬 5 comments Opened Jun 3, 2026 by kieranmcshane

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop can repeatedly restore or prefetch archived/pinned local threads whose state_5.sqlite row points at a missing or pathological rollout. In my profile this made specific sidebar threads unsafe to click and could freeze or severely degrade the renderer.

This overlaps #24510 and #20269, but the distinct part is the stale pinned/sidebar state: archived problem threads could reappear in pinned state and be touched by background restore/prefetch paths.

Environment

Codex Desktop on macOS
Local Codex profile under ~/.codex
State DB: ~/.codex/state_5.sqlite
Local rollouts under ~/.codex/sessions/.../rollout-*.jsonl

User-visible symptoms

Clicking a pinned thread named Find SDP catalog file made Codex Desktop difficult or impossible to click.
Another workstream, Agent 2.1 : upper, also became unsafe to reopen.
The issue could reappear without deliberately opening the old thread, apparently through pinned/sidebar restore or background prefetch.
Updating/restarting Codex Desktop did not fully resolve the affected local profile.

Local evidence

Logs included stale rollout path handling:

state db returned stale rollout path
stale_db_path
failed to resolve rollout path ... No such file or directory (os error 2)

The observed sequence around the stale thread looked like repeated thread/read, thread/resume, and thread/goal/get style lookups.

Large/pathological rollouts were present:

largest observed rollout: about 448 MB
one affected backup: about 184 MB
another affected backup: about 27 MB
individual JSONL lines could be tens of MB, especially compacted/replacement/tool-output payloads

After archiving the affected thread rows, the old IDs still periodically reappeared in pinned-thread-ids. The local guard log showed repeated removals of the same problem IDs. I also found stale entries for those IDs under Electron persisted atom/cache state, including prompt drafts, prompt history, and heartbeat thread permissions.

Workaround used locally

The profile became usable only after doing all of the following:

archive/quarantine the affected rollouts
make the known problem rows archived in state_5.sqlite
remove known-crashing IDs from pinned-thread-ids
keep a local guard running to remove the old IDs when they reappeared
remove stale Electron persisted UI/cache entries for the old thread IDs
resume project work from fresh, small handoff files rather than reopening the original threads

Expected behavior

Missing rollout paths should be treated as recoverable local-state inconsistencies.
Thread list/sidebar/restore paths should remain bounded and lazy.
Pinned/sidebar restore should not fully hydrate an oversized or pathological rollout.
Archived thread IDs should not silently reappear in pinned/sidebar state.
If a rollout is missing or too large to hydrate safely, the app should show a safe recovery action: skip, unpin, archive, locate file, or open lightweight metadata only.

Why this matters

When the affected thread is pinned or restored in the sidebar, the user may not have a reliable UI path to recover because simply selecting the thread can trigger the unsafe path. This turns a single bad local rollout into a profile-level usability problem.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

#25163
#25251
#25215
#26012
#25541

Powered by Codex Action

kieranmcshane · 2 months ago

Thanks for the duplicate suggestions. I reviewed the suggested issues.

I agree this belongs to the same broader Desktop local-history/sidebar/session failure family, but I think this issue is worth keeping open unless maintainers prefer one canonical tracking issue.

How I read the suggested issues:

#25163 is very close: large pinned project thread freezes after update. My case adds stale/missing rollout-path handling and archived/pinned IDs reappearing after local cleanup.
#25251 is related: opening a large thread can peg CPU until restart. My case is more specifically about pinned/sidebar restore or prefetch touching stale or oversized local rollouts.
#25215 is related: long /goal rollouts can exceed resume/list limits. My case is smaller in absolute size, but includes missing rollout paths and stale pinned/sidebar state.
#26012 is related on archive/restore path inconsistency, but focuses on missing command/tool rendering and Windows archive restore. My case focuses on renderer freeze/degraded UI from stale or pathological rollout hydration.
#25541 is related on archived conversations reappearing in the sidebar. My case adds the stale rollout_path / oversized rollout side, where reappearing pinned/sidebar state can trigger an unsafe open/restore path.

The distinct bug I want to preserve here is:

a thread can be archived locally,
its old ID can still reappear in pinned/sidebar UI state,
sidebar restore/prefetch can then touch a missing or pathological rollout,
and opening or restoring that sidebar item can freeze or severely degrade Codex Desktop.

So I would treat this as a bridge issue between the large-rollout hydration reports and the archived/sidebar reconciliation reports. It may ultimately be fixed by the same bounded-history/lazy-hydration work, but the stale pinned/sidebar reappearance path is the additional failure mode captured here.

0xdevalias · 2 months ago

Possibly partially impacted by rust-v0.140.0, but probably not fully resolved. #27031 reduces duplicate rollout-history reads during cold resume, and #27276 speeds archive rollout lookup when the DB lacks a usable rollout path by trying the exact rollout filename before broader search.

#27031
#27276

That may reduce some stalls around oversized/stale rollout restore paths. The stale pinned/sidebar state and missing/pathological rollout behavior described here appear to be separate correctness issues, so a retest on 0.140+ would mostly clarify which parts improved.

botanymint · 1 month ago

Adding another macOS data point: Codex Desktop / bundled CLI 0.142.3 still frequently freezes when opening or interacting with the sidebar.

Observed symptom:

Opening the sidebar often makes the whole Codex app unresponsive.
This has been happening for multiple days.
The issue still reproduces on 0.142.3, so the earlier cold-resume/archive CPU improvements do not fully resolve this sidebar freeze path.

Local read-only diagnostics:

state_5.sqlite: 601 threads total, 485 active, 116 archived
active title + preview + first_user_message metadata: 481,882 chars
~/.codex/sessions: 2.2G
~/.codex/archived_sessions: 498M
~/.codex/logs_2.sqlite: 1.0G
largest active rollout JSONL: about 229 MB
codex doctor --json: state DB integrity OK, rollout DB parity OK; only failure was TERM=dumb, which appears unrelated to the sidebar freeze

Expected behavior:

Opening the sidebar should remain responsive and should not synchronously hydrate or parse large local history/session data.
If a thread/session is too large or stale, the app should skip/lazy-load it or show a recovery action instead of freezing the whole UI.

boombx403-byte · 9 days ago

Hi @kieranmcshane, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.