Codex Desktop: completed child turn visible in UI but read_thread returns items: []

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

• #39885
• #38972

Powered by Codex Action

I reviewed the two suggested duplicates. They appear related, but I believe this report is distinct.

• #39885 concerns a completed response disappearing after restart and the turn rehydrating as interrupted.
• #38972 concerns a turn being reported completed/interrupted while its underlying rollout is still running.
• In this report, the affected turn has genuinely reached completed, and the complete assistant answer remains visibly present in the Codex Desktop UI at the same time that an exact read_thread of that completed turn returns items: [].

Timeline clarification: I had been using this supervising Work -> visible Codex child-thread workflow regularly for several weeks without seeing this failure at all. The Development run in which I first observed it began around midnight local time on August 21, 2026, and I then saw the problem recur multiple times during the same day. So on my setup this appears to be a very recent/intermittent regression rather than a long-standing limitation of the workflow.

I’m leaving this open unless maintainers determine that it shares the same underlying bug as one of the suggested issues.

codex is broke n un useable atm

I traced this against public openai/codex main at 343074d4207d572809bd8cea15f4be1d09d98e0b. The public source suggests a useful four-way diagnostic rather than treating every empty items result as the same failure.

• A successful public app-server turn/completed notification includes the last non-empty agent message as itemsView: "summary" (#34777).
• Paginated history is separately served by thread/items/list and thread/turns/list; summary turns depend on the stored final-agent item reference (#39514). thread/read(includeTurns: true) has an additional persist/full-hydration path (#36993).
• The connector tools named codex_app.read_thread and codex_app.wait_threads are not implemented in this public repository, so their Work/snapshot projection should be tested separately from raw app-server behavior.

For one affected turn, the strongest private capture would compare: (1) raw turn/completed (itemsView, agent item ID), (2) rollout ordering/presence of ItemCompleted(agentMessage) and TurnComplete, and (3) raw results from thread/items/list(turnId), thread/turns/list with both full and summary, and thread/read(includeTurns: true).

That separates the likely boundaries:

• full item list present but summary empty: summary/materialized final-item reference;
• rollout item present but item list empty: SQLite projection/checkpoint failure;
• public app-server surfaces correct but codex_app.read_thread empty: app connector/Work snapshot projection;
• live completion/UI has the message but rollout lacks it: live-to-durable persistence.

On current evidence this remains distinct from #39885 (durable answer rehydrated as interrupted after restart) and #38972 (terminal wake while the rollout is still running). They may share a broader reconciliation class, but neither currently establishes this completed-turn/item-projection contradiction.

This is another projection-layer symptom in the same family: the UI can show a completed child while a connector/read path returns no items. A useful repair diagnostic is to compare raw rollout, thread/items/list, thread/turns/list, thread/read(includeTurns), and thread_history parity rather than trusting one projection.

Additional reproducible evidence from another Windows Codex Desktop user (2026-08-24):

Reproduction pattern

I have two long-lived local Codex task threads that reproduce this consistently. The cross-task reader being used is codex_app__read_thread / codex_app.read_thread — not wait_agent, mailbox, or a consumed completion notification.

1. Fully exit and restart Codex Desktop.
2. From a supervising thread, call read_thread on one affected target thread.
3. The first read after restart succeeds and returns the full userMessage and agentMessage.
4. Let the target thread complete a new short turn.
5. Codex Desktop UI shows the full assistant answer and can navigate to the exact latest turn.
6. read_thread resolves the same thread/turn and reports status=completed, but returns:

items=[]
latestAssistantMessage=null

1. Further reads remain empty. After another full Codex restart, the target becomes readable again once, then the failure recurs after later/new turns.

Controls / recovery attempts already tested

• Other newly created tasks can still be read normally.
• The same two older affected tasks reproduce the issue repeatedly.
• Forking an affected task does not fix it; the fork also reproduces the unreadable-result behavior.
• Uninstalling/reinstalling Codex Desktop and rebooting Windows did not fix it.
• Signing out and signing back in did not fix it.
• The Desktop UI continues to show the complete answer throughout.
• Read-only inspection of the corresponding local raw session source can still recover the full assistant text after read_thread returns empty, which indicates the answer is durably present somewhere locally rather than actually lost.
• No SQLite, rollout JSONL, task metadata, or internal index files were modified during these tests.

Why this seems important

The especially distinctive signal is cold restart -> one successful full read -> later/new completed turns project as empty until the next restart. That behavior looks more like a warm/incremental projection, hydration, or runtime synchronization problem between durable session data and codex_app.read_thread, rather than authentication failure, permanent thread corruption, or one-shot notification consumption.

The UI/raw-session/read-thread contradiction is therefore:

Desktop UI:                full assistant answer visible
Local raw session source:  full assistant answer present
read_thread:               exact completed turn found, but items=[]
latestAssistantMessage:    null

If useful, I can provide sanitized screenshots and exact private thread/turn IDs to OpenAI privately.

Additional sanitized reproduction from a Remote SSH-backed Codex task:

• Backing host reported by the app: remote-ssh-discovered.
• Remote environment: Linux aarch64 under OrbStack; codex-cli 0.149.1.
• In one thread, an older completed turn returned 500 structured items, while each of two later completed turns returned the exact turn metadata but items: [].
• The result was unchanged with includeOutputs false or true.
• Both affected turns had nonzero duration and produced durable task-state/workspace effects, so they were not actually empty executions.
• The target thread was idle/completed when reread.
• The remote local Codex store did not contain the affected turn IDs, consistent with a projection or replication boundary rather than a wrong-thread lookup.

Private thread/turn IDs and sanitized read_thread results can be provided to OpenAI privately if useful.

Additional sanitised reproduction from Windows 25H2 narrows this beyond a stale or incomplete SQLite projection.

Environment

• Codex Desktop MSIX: 26.818.8289.0
• Codex command runner: 0.149.0-alpha.4.3
• Platform: Microsoft Windows NT 10.0.26200.9168, x64
• Reproduced across two provider routes, including Cursor through a local proxy and an independent gpt-5.6-sol task

Projection parity from one affected completed turn

The canonical rollout contains:

• 372 persisted records
• 208 event_msg/item_completed events
• 30 tool calls and 30 tool outputs
• final assistant item at rollout ordinal 1718
• task_complete at ordinal 1721

The matching local thread_history_1.sqlite projection also contains all 208 expected item rows and the correct final_agent_item_id.

The materialisation cursor is fully caught up, not stale:

rollout file size              5,975,010
next_rollout_byte_offset       5,975,010
last rollout ordinal           1721
next_rollout_ordinal           1722

Despite that parity, an exact supported read_thread still reports the completed turn with items: [].

Cross-provider and date-boundary control

In the affected task, a completed pre-midnight turn returns its full items, while two completed turns after UTC midnight return items: [].

A separate gpt-5.6-sol task shows the same boundary: its pre-midnight turn is readable, while its completed post-midnight turns return items: []. This clears the Cursor provider and local proxy as necessary causes.

The strongest current correlation is therefore a turn completed after UTC midnight inside a rollout created and stored under the previous date. That may point to a date-partition or rollover filter in the history read/serialisation path.

This evidence places the failure downstream of both canonical rollout persistence and SQLite materialisation. It is therefore distinct from #38792-style cases where the projection cursor itself is desynchronised.

No raw rollout, prompt, local path, account data or private thread identifier is attached.

Additional sanitized Remote SSH reproduction with canonical persistence evidence.

Environment:

• Codex Desktop controlling a remote Linux task
• remote task session metadata: codex-cli 0.147.0
• the task was idle after completion

Observed:

• the complete final assistant response remained visible in the task UI;
• the latest two turns were both reported as completed, but an exact fresh read_thread returned items: [] for both;
• for the latest turn, wait_threads reported a completed duration of 113,640 ms while latestAssistantMessage and latestToolMarkerId were both null.

A read-only parse of the canonical remote JSONL for that exact latest turn found:

• 34 persisted response_item records;
• 9 tool calls and 9 matching tool outputs;
• 3 persisted assistant messages;
• a persisted task_complete event.

No rollout or database state was modified during this check.

This rules out an actually empty model turn. The assistant output and completion are durable, while both structured task projections discard every item for the completed turn. It is the Remote SSH-backed form of the UI/raw-session/read-thread contradiction described in this issue.

No task IDs, turn IDs, hostnames, addresses, repository names, paths, prompts, credentials, or account data are included.

For information, workaround that restored my workflow: the parent still tries the native cross-thread result/read path first. If that fails with the empty-item behavior described in this issue, it falls back to a transcript written by the child itself.

The child writes its prompt/result transcript to an expected location in the shared filesystem before completing. The parent can then read that file directly and continue the workflow without requiring manual copy/paste.

This is only a workaround for the failed structured read path, not a solution to the underlying issue.

Additional reproduction from 2026-08-27 (Windows Codex Desktop supervising a Remote SSH-backed task):

• The target thread is an existing remote-SSH task on a Linux host.
• read_thread returned the target thread metadata and completed turn records, but the latest completed turns had items: [].
• includeOutputs: true did not restore any assistant message items.
• The Desktop/UI-side task was visibly showing the assistant response, while the structured reader exposed no latest assistant message.
• Re-reading after the turn became idle/completed still returned empty items.
• A separate current local kubectl check is unrelated; the failure is specifically the cross-thread read/projection path.

This matches the UI-visible / read_thread-empty contradiction described here, including the Remote SSH-backed variant. No credentials, private keys, or raw task contents are included.