`spawn_agent` with an explicit model and reasoning override is reported incorrectly when `fork_context=true`.

Resolved 💬 4 comments Opened Mar 31, 2026 by tomas-langer Closed Mar 31, 2026

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

not sure

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.17.0-19-generic x86_64 unknown

What terminal emulator and version are you using (if applicable)?

wezterm 20240203-110809-5046fc22

What issue are you seeing?

Agent Spawn Reporting Bug

Completed on 2026-04-01.

Summary

spawn_agent with an explicit model and reasoning override is reported incorrectly when fork_context=true.

The requested child override is recorded correctly in the parent spawn event, but the forked child session persists a copied parent turn_context that says gpt-5.4 with xhigh reasoning. The child runtime still executes on the requested model, so the visible Spawned ... (gpt-5.4 xhigh) line appears to be caused by stale forked metadata rather than by the wrong model actually running.

What steps can reproduce the bug?

Parent session defaults:

  • model: gpt-5.4
  • reasoning: xhigh

Spawn a child with:

{
  "agent_type": "default",
  "fork_context": true,
  "model": "gpt-5.1-codex-mini",
  "reasoning_effort": "medium",
  "message": "Reply with exactly: pong-fork"
}

Control case:

  • Repeat the same spawn with fork_context=false.

What is the expected behavior?

The visible spawned-agent label, the child session metadata, and the runtime logs should all agree on:

  • model: gpt-5.1-codex-mini
  • reasoning: medium

Additional information

Actual

  • The parent spawn event records the requested override correctly.
  • The non-forked child records the override correctly.
  • The forked child persists gpt-5.4 / xhigh in its turn_context.
  • The forked child runtime still starts and sends requests as gpt-5.1-codex-mini.

Evidence

  • Parent spawn event for the non-forked control records gpt-5.1-codex-mini / medium:

~/.codex/sessions/2026/03/31/rollout-2026-03-31T23-56-26-019d45e5-e180-7253-9073-55b9880a09bf.jsonl:49

  • Non-forked child turn_context also records gpt-5.1-codex-mini / medium:

~/.codex/sessions/2026/03/31/rollout-2026-03-31T23-57-32-019d45e6-e2a1-7c72-9d1b-3d6b832aba7e.jsonl:5

  • Parent spawn event for the forked case still records gpt-5.1-codex-mini / medium:

~/.codex/sessions/2026/03/31/rollout-2026-03-31T23-56-26-019d45e5-e180-7253-9073-55b9880a09bf.jsonl:185

  • Forked child turn_context incorrectly persists the parent values gpt-5.4 / xhigh:

~/.codex/sessions/2026/03/31/rollout-2026-03-31T23-59-18-019d45e8-7f50-7fc1-a170-f92cfb8a6221.jsonl:6

  • The forked child runtime still starts the turn on gpt-5.1-codex-mini:

~/.codex/log/codex-tui.log:307927

  • The forked child runtime sends the response request on gpt-5.1-codex-mini:

~/.codex/log/codex-tui.log:307935

  • The forked child runtime closes the response request on gpt-5.1-codex-mini:

~/.codex/log/codex-tui.log:307937

Conclusion

The defect appears to be in forked-session metadata initialization or in the renderer that reads that metadata:

  • collab_agent_spawn_end carries the correct requested override.
  • The forked child session file persists stale parent turn_context values.
  • Runtime model selection still follows the requested override.

The most likely fix is in the fork_context=true child-session initialization path: do not copy the parent turn_context model/reasoning fields into the child session metadata, or ensure the child session rewrites them from the explicit spawn override before persistence and display.

View original on GitHub ↗

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