[Thread API] read_thread omits completed response after context compaction

What version of the Codex App are you using?

Codex task-management API surface in Codex Desktop.

• Bundled runtime recorded by the affected session: codex-cli 0.150.0-alpha.8
• Current local CLI: codex-cli 0.149.1
• Platform: macOS Darwin 24.6.0 arm64
• Affected task source: vscode
• Model: not surfaced in the session metadata

What issue are you seeing?

After a target task performs context compaction, a cross-thread read can silently omit the target task's latest completed assistant response.

The task completes normally and the raw rollout JSONL contains the final assistant message. However, the thread-management API reports the latest turn as completed while returning an empty item list and no latest assistant message. This makes read-only cross-thread review and handoff retrieval fail even though the response is persisted locally.

The compaction correlation is evidence from one reproduction, not a confirmed causal mechanism.

Reproduction

1. Use a sufficiently long-running Codex task that performs context compaction.
2. From another task, send a read-only review request to that task.
3. Wait for the target task to finish.
4. Call wait_threads and then read_thread for the exact target thread ID.
5. Observe that the target turn is completed, but its retrievable items are empty.
6. Inspect the local rollout JSONL and observe that the assistant response is present.

Affected task:

01a03fe0-2471-7ec2-a29f-6117f1f3f022

Observed local rollout evidence:

• compacted record at ordinal 2015, timestamp 2026-08-26T21:26:58.831Z
• assistant response_item at ordinal 2093
• task_complete at ordinal 2095, with a non-empty last_agent_message
• read_thread / wait_threads result: latest turn completed, but items: [], latestAssistantMessageId: null, and latestAssistantMessage: null

The raw response remains in:

~/.codex/sessions/2026/08/26/rollout-2026-08-26T23-00-49-01a03fe0-2471-7ec2-a29f-6117f1f3f022.jsonl

Older assistant messages from the same task were retrievable, so this is not simply lack of access to the task.

Expected behavior

A completed target turn should expose its assistant response through read_thread, regardless of whether context compaction occurred. If transcript hydration fails, the API should return an explicit error or incomplete-state marker rather than a successful completed turn with an empty transcript.

Actual behavior

The status path correctly observes completion, but the transcript path silently drops the latest response. Repeated waiting does not restore it. Reading the raw rollout JSONL recovers the response, but that is an internal, unsupported fallback and is not available for remote tasks.

Related issues

• #38169: heavily compacted thread/resume silently drops newest turns
• #37030: cross-thread delegation can lose model-visible thread history
• #28193: exact transcript access for the assistant
• #20493: blank thread views despite intact local JSONL transcripts

This report is narrower: the target task completes, local storage contains the assistant message, but the cross-thread read_thread result omits it after compaction.

Privacy

The raw transcript is not attached because it contains private project conversation and local paths. The rollout path, task ID, turn status, ordinals, and metadata above are sanitized evidence.

Start with the read_thread and wait_threads entry points and reproduce the case using the affected thread ID. Compare their returned items and latest-assistant fields with the recorded rollout JSONL, especially the compacted record, response_item, and task_complete entries. Done means a completed target turn exposes its assistant response, or reports an explicit incomplete or error state instead of an empty successful transcript.