resume_agent restores subagent history but not original model/reasoning settings
What version of Codex CLI is running?
Observed while investigating codex-cli 0.137.0; I also checked current main and did not find resume-time restoration of the child thread model/reasoning settings from the rollout TurnContextItem.
What subscription do you have?
N/A - source-level bug report.
Which model were you using?
N/A. The bug is about resuming a previously spawned subagent whose stored turn context used a different model/reasoning effort than the parent/current session.
What platform is your computer?
Linux x86_64.
What terminal emulator and version are you using, if applicable?
N/A.
Codex doctor report
Not available for this source-level report.
What issue are you seeing?
resume_agent can restore a subagent thread history without restoring the subagent's original runtime model/reasoning settings.
For a spawned custom subagent, the rollout contains TurnContextItem entries recording the child turn context, including model, explicit effort, and/or collaboration_mode. However, the resume path constructs the resumed session from the caller-provided/current Config and the rollout history. It does not appear to apply the latest persisted TurnContextItem back onto the Config before starting the resumed session.
The result is that a resumed subagent can silently run under the current parent/default model and reasoning effort rather than the child thread's original custom-agent settings. This is especially visible for project/custom agents that pin a cheaper or narrower model, e.g. model = "gpt-5.4-mini" and model_reasoning_effort = "medium", while the parent uses a larger/high-effort model.
What steps can reproduce the bug?
One source-level reproduction approach:
- Spawn a custom subagent whose role config sets a different model/reasoning effort than the parent session, for example:
name = "researcher"
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
developer_instructions = "Act as a read-only researcher."
- Let the child run at least one turn so the rollout persists a
TurnContextItemfor the child with that model/reasoning configuration.
- Resume the child thread via
resume_agentfrom a parent/current config using a different model/reasoning effort.
- Inspect the resumed session config or emitted turn context. The resumed session can use the current/default config instead of the latest persisted child
TurnContextItem.
A focused unit test also demonstrates the issue: build a stored rollout with a latest RolloutItem::TurnContext whose model and effort differ from the supplied resume config, invoke the resume path, and assert the resumed config uses the rollout values. That assertion fails without applying the persisted turn context before session creation.
What is the expected behavior?
When resuming a subagent thread, Codex should preserve the subagent's original runtime settings from the latest persisted child TurnContextItem, at least for:
model- explicit
effort, or the effort implied bycollaboration_modewheneffortis absent
This keeps resumed custom agents consistent with the model/reasoning configuration they were spawned with.
Additional information
A minimal patch outline that worked locally:
- in the resume-from-rollout path, after loading rollout history and before constructing the resumed session, find the latest
RolloutItem::TurnContext; - set
config.model = Some(turn_context.model.clone()); - set
config.model_reasoning_effort = turn_context.effort.or_else(|| turn_context.collaboration_mode.as_ref()?.reasoning_effort()); - add regression coverage that resumes from a rollout whose latest
TurnContextItemuses a different model/effort than the supplied config.
This is related to custom subagent configuration issues such as #26363/#26408, but it is a separate resume-time consistency problem: even if spawn applies the custom role correctly, resume can lose the child's original runtime settings.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗