›_ Codex Issues
Codex Issues / #20418

Codex Desktop archived automation runs stay red and cannot be opened even though thread/resume succeeds

Open 💬 3 comments Opened Apr 30, 2026 by cyjjjj-21
💡 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)?

26.422.71525 (2210)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

In Codex Desktop's automation history, recent archived automation runs show a red unread dot and cannot be opened by clicking them, even though the automation itself completed successfully and its archived thread/result still exists on disk.

On this machine, the affected examples are recent Night Memory Pipeline runs in the archived history list. Clicking a run does not open any result view.

The backend state looks healthy:

  • ~/.codex/sqlite/codex-dev.db shows these runs as ARCHIVED, not FAILED.
  • ~/.codex/state_5.sqlite still contains the matching thread rows.
  • threads.rollout_path points to real files under ~/.codex/archived_sessions/.
  • ~/.codex/session_index.jsonl still contains the corresponding thread ids.
  • ~/.codex/logs_2.sqlite shows Codex Desktop issuing thread/resume for the archived thread, and the backend successfully initializes the thread / creates a shell snapshot.

Despite that, the Desktop UI does not show the archived result, and automation_runs.read_at remains null, so the red dot never clears.

What steps can reproduce the bug?

  1. In Codex Desktop on macOS, have an automation complete successfully and move into archived history.
  2. Open the automation history / archived runs list.
  3. Click an archived successful run such as Night Memory Pipeline.
  4. Observe that no result view opens.

Concrete local evidence from one affected run:

  • automation id: night-memory-pipeline
  • thread id: 019dda66-abc7-7f61-a31f-429b37232599
  • run status in automation_runs: ARCHIVED
  • read_at: NULL
  • archived rollout file exists at:

/Users/chenyuanjie/.codex/archived_sessions/rollout-2026-04-30T02-00-54-019dda66-abc7-7f61-a31f-429b37232599.jsonl

Additional backend observation:

  • In ~/.codex/logs_2.sqlite, clicking this archived run triggers a Desktop thread/resume request for thread 019dda66-abc7-7f61-a31f-429b37232599.
  • The resume path succeeds far enough to log Shell snapshot successfully created, so this does not look like missing rollout data or a missing thread.

What is the expected behavior?

Clicking a successful archived automation run should open its archived result thread/output.

If the archived result opens successfully, the run should also be marked read so the red unread dot clears.

Additional information

This looks like a Desktop UI/navigation regression rather than corrupted automation output:

  • the automation did run
  • the archived session file exists
  • the thread index exists
  • the backend can still resume the archived thread
  • but the result view never appears in the app

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #18216

Powered by Codex Action

cyjjjj-21 · 3 months ago

Thanks. I reviewed #18216, and it does look closely related and likely shares the same underlying archived-thread opening/navigation failure in Codex Desktop.

My case is specifically through the archived automation history entry point: clicking a successful archived automation run does not open the archived result thread/output, and the run also remains unread (automation_runs.read_at stays NULL, so the red dot never clears).

So this may be the same root cause, but with an additional automation-run UI symptom layered on top. I’m leaving this issue open for now in case that distinction is useful for tracking or verification.

shleder · 11 days ago

The archived rollout existing while the Desktop result view stays inaccessible makes this a useful archive/index parity case for codex-rescue==0.1.0a4.

If you still have the affected archived session, could you try a read-only pass:

pipx install codex-rescue==0.1.0a4
codex-rescue sessions
codex-rescue doctor --json "/path/to/the-archived-rollout.jsonl"

It won’t fix Desktop navigation or read_at, but it can independently validate whether the archived transcript itself is structurally healthy and recoverable.

Please share only sanitized status/findings/counts. Don’t post raw rollouts, SQLite DBs, automation contents, prompts, tool output, credentials, session IDs, or private paths.