Codex App loses thread history after cross-thread delegation messages

What version of the Codex App are you using?

Codex App 26.730.61639 (bundle build 6234)

Bundled runtime: codex-cli 0.147.0-alpha.1.2

What subscription do you have?

Unknown / not surfaced in the local trace.

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

A long-running Codex App thread can lose its model-visible conversation history after it receives a background cross-thread delegation message. The complete transcript remains present in the UI and local session JSONL, and read_thread can still retrieve the previous turns. However, subsequent model requests contain only the latest prompt and the assistant responds as if it cannot see earlier turns.

This is different from normal context compaction: there was no new contextCompaction event at either failure boundary, and no summary of recent turns was supplied. The model and effort also remained unchanged (gpt-5.6-sol, xhigh).

Observed thread/session ID: 019fcff5-1191-7080-8441-4a94e1297845

What steps can reproduce the bug?

1. Create or resume a long-running Codex App thread. In this case, the thread was forked from an older local thread, used history_mode: legacy, and contained earlier compactions.
2. Have another Codex task send a background handoff/delegation message to the main thread. It is stored as a user message wrapped in <codex_delegation>.
3. Continue chatting in the main thread and ask a follow-up that depends on the immediately preceding turns.
4. Observe that the assistant gives a generic answer or explicitly says that only the current message is visible.
5. Inspect the session trace. The full transcript is still stored, but request token usage collapses to approximately the size of the new prompt.

Two observed transitions:

• Before the first delegation, a normal request used 115,650 input tokens (110,336 cached). The delegation request used only 177 input tokens (0 cached). The following direct user turns used 62, 15, and 17 input tokens.
• After context was later rehydrated, a normal request used 190,230 input tokens (182,016 cached). The next delegation request used only 181 input tokens (0 cached). Subsequent turns used 236, 569, 14, 476, and 19 input tokens, all with 0 cached input tokens.

The first failure temporarily recovered only when a later turn received a fresh developer skills block and world_state; input then returned to 127,493 tokens. The second failure did not recover within the observed session.

No new compaction event or model switch occurred at either transition. This suggests that the background delegation path starts or continues a stateless/short request chain without rehydrating the existing thread history. That last sentence is an inference from the trace; the client trace does not expose the server-side previous-response/context pointer.

What is the expected behavior?

A background delegation message should append to the existing thread while preserving its active history or compacted summary. Follow-up turns should retain at least the recent conversation and durable task state. If the history cannot be restored, the App should surface an explicit recovery error instead of silently starting a current-message-only chain.

Additional information

The affected thread was forked from an older session and had nine historical compaction records, but the failures occurred later without new compaction events.

The raw transcript is not attached publicly because it contains project conversation content and local paths. I can provide sanitized trace excerpts or upload the session through the in-product /feedback flow if maintainers need them.