Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex Desktop archived automation runs stay red and cannot be opened even though thread/resume succeeds [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20418•Fetched 2026-05-01 05:43:16
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
cyjjjj-21cyjjjj-21
Participants
cyjjjj-21cyjjjj-21github-actions[bot]github-actions[bot]
Timeline (top)
labeled ×3commented ×1
RAW_BUFFERClick to expand / collapse

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

extent analysis

TL;DR

The issue can be resolved by investigating and fixing the Desktop UI/navigation logic that handles archived automation runs, specifically focusing on why the read_at field remains null and the result view fails to open.

Guidance

  • Verify that the thread/resume request is correctly handled by the backend and that the response is properly processed by the Desktop UI.
  • Check the Desktop UI code for any recent changes or updates that might have introduced this regression, particularly in the archived runs list and result view rendering logic.
  • Investigate why the automation_runs.read_at field remains null even after a successful automation run and archived thread resume.
  • Review the logging in ~/.codex/logs_2.sqlite to ensure that there are no errors or warnings related to the thread/resume request or the rendering of the archived result view.

Example

No specific code snippet can be provided without more information about the Codex App's codebase, but the investigation should focus on the UI components responsible for handling archived automation runs and the backend API that serves the archived thread data.

Notes

The issue seems to be specific to the Desktop UI and navigation, rather than a problem with the automation runs themselves or the backend data storage. The fact that the backend can resume the archived thread and log a successful shell snapshot creation suggests that the data is intact, but the UI fails to properly display it.

Recommendation

Apply a workaround by manually updating the read_at field for the affected automation runs, if possible, and investigate the UI code for the root cause of the issue, as this seems to be a regression rather than a data corruption problem.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#network issue#logging issue#authentication issue#prompt issue#agent setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop archived automation runs stay red and cannot be opened even though thread/resume succeeds [1 comments, 2 participants]