resume_agent restores subagent history but not original model/reasoning settings

Open 💬 3 comments Opened Jun 6, 2026 by umiskky

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:

  1. 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."
  1. Let the child run at least one turn so the rollout persists a TurnContextItem for the child with that model/reasoning configuration.
  1. Resume the child thread via resume_agent from a parent/current config using a different model/reasoning effort.
  1. 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 by collaboration_mode when effort is 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 TurnContextItem uses 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗