Allow the parent agent to decide whether to send the full history when spawning a sub-agent.

What variant of Codex are you using?

App, CLI

What feature would you like to see?

According to thread_manager.rs, when the parent agent spawns a subagent, the history is always InitialHistory::New.

However, in many development scenarios, we want the sub-agent to have access to the full conversation history. For example, after multiple rounds of dialogue with the parent agent, various fragmented consensus points, directions, or specs may have formed. This information is often too complex for the parent agent to autonomously summarize and pass to the sub-agent during a tool call.

Suppose a conversation with the parent agent has already generated 50k tokens of context. At this point, a sub-agent is assigned a complex task that requires the full context to be executed correctly. If the parent agent is forced to generate a 10k-token summary to send to the sub-agent:

1. The 10k summary might miss critical details, leading to imperfect execution.
2. Generating 10k tokens of tool parameters consumes significant time.
3. It may cause the parent's context to bloat from 50k to 60k (I am unsure if the context passed to the sub-agent is retained in the parent's history as a tool argument).

This brings us to a question: Under what circumstances should a sub-agent be used?
My understanding is that the primary benefit of a sub-agent is to help the parent agent maintain a clean context, preventing subsequent tasks from being distracted by the noise of granular execution history, which would otherwise degrade generation quality. Saving tokens is secondary. From this perspective, a sub-agent shouldn’t just be viewed as an "outsourced worker" limited to simple tasks requiring brief context; it can also be a clone of the parent agent that shares the same full context.

Therefore, I suggest exposing parameters that allow the agent to decide whether to pass the full history when calling a sub-agent. Additionally, a preference setting could be provided to let users decide whether to enable this feature.

Additional information

_No response_