Desktop fork stores full history but agent receives missing or unrelated context

What version of the Codex App are you using?

OpenAI.Codex 26.707.3748.0 (Windows x64)

What issue are you seeing?

A normal same-directory fork contains the source thread's completed raw turns, but the agent in the fork does not receive or recognize the complete conversation history. It can claim that a specific earlier response is absent even though that exact response is present in the forked thread data. The context available to the agent may instead contain incomplete or seemingly unrelated task information.

This makes normal forking unreliable for continuing work from an earlier point.

Steps to reproduce

1. Open a Codex Desktop task with a substantial completed conversation history.
2. Wait for the active response to finish.
3. Create a normal fork (same directory, not a worktree fork).
4. In the fork, ask the agent whether it can see a specific completed assistant response from the source task.
5. The agent says it cannot see that response or describes different context.
6. Inspect the fork using the app's thread-reading interface: the supposedly missing user and assistant turns are present in the fork's stored history.
7. Paste the missing response manually; the agent can then use it normally.

Expected behavior

A normal fork should provide the agent with the completed conversation history copied into the child thread, including earlier user messages, assistant responses, decisions, and task state.

Actual behavior

The child thread stores the correct raw turns, but the model-visible context is incomplete or reconstructed from an incorrect/insufficient summary. The agent denies seeing messages that demonstrably exist in the fork.

Evidence from this reproduction

• Source and fork used the same workspace directory.
• The missing response was a completed final assistant response, not an active or interrupted turn.
• Reading the child thread showed the exact missing response in its raw turn list.
• The child agent nevertheless explicitly stated that it did not see that response until it was pasted again.
• No data appears to have been lost at the persistence layer; the failure appears between persisted fork history and model-context construction/compaction.

Impact

Forking cannot be trusted for branching long planning or implementation conversations. Users may unknowingly continue with missing decisions or unrelated context, leading to incorrect changes.

Related issues

• #17354 — stored history remains present while app-visible/runtime history is missing
• #14347 — context compaction can lose earlier history
• #19045 — thread/fork can fail to inject expected model-visible context on the first turn (developer-instruction-specific)
• #8310 — resumed sessions can lose task intent and continue with unrelated context

This appears distinct because it specifically reproduces on a normal Desktop fork, and the complete raw turns are verifiably present in the child thread while unavailable to the child agent.