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

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.