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

Summary

On Codex Desktop for Windows, a completed child turn can be fully visible in the Desktop conversation UI while both the supervising Work task's immediate delegation result and a later exact codex_app.read_thread of that same completed turn expose no assistant message items.

The affected turn is not missing from the task: read_thread can locate the exact completed turn record and completion metadata, but returns items: []. The Desktop UI simultaneously shows the complete assistant answer.

This has happened intermittently across multiple child turns. Older turns in the same child thread remain readable through read_thread, so this is not a wrong-thread/project lookup or a permanently broken read_thread tool.

Environment

• OS: Windows 11 Pro 25H2
• Windows build: 26200.9168
• Installed package: OpenAI.Codex
• AppX/MSIX version: 26.818.4152.0
• ChatGPT/Codex About version: 26.818.32112
• About release date shown by the app: 21 Aug 2026
• Host type: local Codex Desktop project/thread
• The workflow uses a supervising Work thread delegating implementation to a visible local Codex child via the codex_app thread tools.

The exact private thread/turn IDs and screenshots can be provided to OpenAI privately if useful.

What issue are you seeing?

A typical failure sequence is:

1. The supervising Work task sends a prompt to an existing local Codex child.
2. The child executes normally and the turn reaches completed.
3. The answer is visibly present in the Codex Desktop UI.
4. The immediate Work-side completion/result path returns zero visible items.
5. A later codex_app.read_thread against the exact same child, using fresh pagination to the exact completed turn, finds the turn record but returns:

items: []

6. codex_app.wait_threads reports the turn as completed but exposes no latest assistant message.
7. Re-listing/re-resolving the exact child, reading with and without outputs, omitting/including the local host id, loading the task in the UI, waiting briefly, and rereading do not restore the structured message items.
8. The answer remains visibly readable in the Desktop UI throughout.

The contradiction is therefore:

Desktop UI: full assistant answer visible
read_thread: same completed turn exists, but items: []

Strong evidence from one recent occurrence

Three consecutive turns in the same child showed the problem:

Request	Turn state	Immediate result	Exact retained read_thread
substantive correction	completed	zero items	exact turn found, items: []
substantive handoff	completed	zero items	exact turn found, items: []
one-line no-tools marker	completed	zero items	exact turn found, items: []

The third request intentionally asked for exactly one short line and no tools. The UI displayed the exact one-line answer, but the immediate result and later read_thread both still exposed zero items. This rules out answer length, Markdown complexity, tool use, and long execution time as necessary causes.

In earlier occurrences, the same class of symptom survived loading the exact task and even an app/computer restart while the persisted answer later became readable.

Intermittent behavior

This is not a persistent configuration failure:

• earlier child turns returned normally;
• later turns in the same child can fail;
• normal turns can occur again afterward;
• older turns in the same affected child remain readable with read_thread;
• the same saved project, local host, source Work thread relationship, and child identity are used in both working and failing cases.

The earliest related symptom I observed was a completed child turn where progress was visible but the final report was omitted from the supervising task result. Later occurrences became stronger all-items-empty failures.

Checks already performed

The following were verified during the failure:

• exact child/thread identity is correct;
• exact completed-turn identity is correct;
• source Work-thread relationship is correct;
• saved project/workspace binding is correct;
• host is local;
• there is no replacement-child or stale-task mismatch;
• fresh read_thread pagination locates the exact target turn;
• old cursors are not being reused;
• reading with/without included outputs makes no difference;
• including/omitting hostId makes no difference;
• re-listing/re-resolving the child makes no difference;
• loading/navigating to the exact task and rereading makes no difference;
• the task is completed/idle, not still running;
• no repository, Git, or test-execution state correlates with the retrieval failure.

The same read_thread + pagination mechanism successfully reads older turns in the exact same child.

Expected behavior

When a local child turn reaches completed and the Desktop UI can display its assistant answer, codex_app.read_thread should return that same persisted visible assistant message for the completed turn.

At minimum, these surfaces should agree on whether the completed answer exists:

• Desktop conversation UI
• immediate supervising-thread completion/result
• codex_app.wait_threads latest-assistant state
• codex_app.read_thread retained turn items

A completed answer should not be visible in one surface while represented as an empty completed turn in another.

Impact

This is particularly disruptive for agentic Work -> Codex orchestration:

• the supervising Work task cannot independently review the child's exact answer even though the user can see it;
• the workflow may unnecessarily resend prompts, consuming request allowance and potentially duplicating work;
• automated transcript/archive maintenance sees an apparent message gap despite the answer being visible in the UI;
• the only recovery in the strongest cases is manual user relay of the visible answer from the UI.

A short-term safe workflow is to avoid resending immediately, try an exact retained-thread read first, and ask for manual relay only if the exact completed turn still exposes no assistant items.

Possibly related issues

Possibly related, but not duplicates:

• #24287 — Desktop/backend turn-state desynchronization and invisible/misleading turn state.
• #37620 — durable thread history and another model-visible/read surface diverging.
• #30385 / #26634 — different Desktop thread-index/read-surface inconsistencies.

This report is distinct because the Desktop UI has the completed answer while an exact read_thread of the same completed turn returns an empty item list.

Additional context

The app received several visible updates around the observation window. The Aug 20 update notes included thread-related features such as shared thread snapshots and unified pinned threads. I do not know whether those changes are related and am not claiming causation.

A second Work/Codex Desktop instance was also active in a separate VM on the same account during one recent occurrence. The two instances used separate local filesystems/projects. This is noted only as an environmental variable; the symptom had occurred earlier as well, so concurrent VM activity is not established as necessary or causal.

If useful, I can provide privately:

• exact child/turn IDs;
• screenshots showing the answer visible in the Desktop UI;
• sanitized read_thread/wait_threads results for the same turn;
• a chronology of working vs failing turns within the same child.

Start by tracing the codex_app.read_thread and codex_app.wait_threads entry points and comparing their completed-turn items with what the Desktop conversation UI displays. Reproduce the intermittent empty-items result using the exact retained child turn, then verify that the UI, supervising result, wait_threads state, and read_thread items agree for completed answers.