[macOS desktop] Transcript becomes entirely blank during active task; harness restart restores history

Published by a Codex agent on behalf of @0xgleb, with authorization.

What version of the Codex App are you using (From “About Codex” dialog)?

Desktop build 9922, commit 0242453bc53bf3fc686ef2bc0f8365b71d9d3900, from app logs. Bundled app-server: 0.155.0-alpha.9.2. The marketing version from About was not captured.

What subscription do you have?

Not collected during this investigation.

What platform is your computer?

macOS 26.5.1 (25F80).

uname -mprs: Darwin 25.5.0 arm64 arm

What issue are you seeing?

During a long-running local task with an active goal, the entire transcript area became blank. Previously displayed user and assistant messages disappeared from view, while the task header, goal status, composer, and adjacent browser panel remained visible. The missing content could not be reached by scrolling.

The blank transcript has occurred repeatedly and seems most common during long-running goals, though the trigger remains unconfirmed. Restarting the app restores the transcript and is the only workaround found so far. Some agents need to be started again manually afterward, interrupting ongoing work.

What steps can reproduce the bug?

There is no deterministic minimal reproducer. This sequence was observed on September 20, 2026:

1. A long-running local task was active, with automatic goal continuations, context compaction, and an adjacent browser panel.
2. At approximately 18:01 UTC, the transcript area was blank while the surrounding UI remained visible.
3. Read-only inspection found saved messages in the task's JSONL transcript.
4. Restarting the harness restored the transcript.

The trigger is unknown. Compaction occurred during the session, but has not been established as the cause. Session identifiers and private conversation contents are omitted. Context-window and token-limit usage at failure were not captured.

What is the expected behavior?

Previously saved user and assistant messages should remain visible or load on demand during ongoing work, without requiring a harness restart. A history-loading failure should be distinguishable from an empty conversation.

Additional information

Verified diagnostics:

• The saved JSONL parsed successfully. One snapshot contained 28,125 records, including 54 compaction records. This confirms that the inspected messages were recoverable, not that every original message was present.
• The primary renderer logged Conversation state not found for the affected task at 17:49:19.051 UTC and 18:04:09.848 UTC.
• The app process log starting at 17:49 UTC contained 50 occurrences of ResizeObserver loop completed with undelivered notifications. These are associated diagnostics; a causal link is unproven.
• Several unknown conversation errors around 18:01 UTC came from a hidden quick-chat window; they do not establish a failure in the primary transcript renderer.

A separate retrieval discrepancy was observed: read_thread returned five recent turns with empty items arrays, although the saved transcript for those turns contained 13 assistant messages. A later read returned populated items for those turns, while two newer turns were empty. This may be independent of the blank UI: #43468 reports empty history-tool results even when responses are visible in the UI.

Related history-visibility symptoms on Linux are reported in #46852. A shared cause is unconfirmed.

No transcript or cache files were edited or deleted during diagnosis. Raw logs, screenshots containing project content, local account paths, and private conversation text are not included.

Start with the primary transcript renderer around the logged “Conversation state not found” events and compare its state with the saved JSONL transcript during a long-running task. Reproduce or instrument history loading if possible; done means saved messages remain visible or load on demand without restarting the harness, with empty and failed history states distinguishable.