What version of the Codex App are you using (From “About Codex” dialog)?
26.810.52044 (build 6662)
What subscription do you have?
Managed work account (exact subscription tier is not displayed in the App)
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
The Codex App activity transcript can make a single successfully created subagent look as if it was spawned multiple times.
In this reproduction, exactly one explorer agent was created successfully. Before that success, two spawn_agent calls were rejected during parameter validation:
- The first attempt failed with:
Full-history forked agents inherit the parent agent type; omit agent_type, or spawn without a full-history fork.
- The second attempt failed with:
Unknown model openai.gpt-5.6-sol for spawn_agent. Available models: gpt-5.6-sol.
- The corrected retry succeeded and created one agent.
The App retained the two rejected calls as separate expanded Creating an agent cards instead of marking them failed. This makes the transcript look like duplicate successful spawns even though only one agent instance was created. The two cards contain slightly different retry inputs, confirming this is misleading lifecycle rendering rather than duplicate backend creation.
What steps can reproduce the bug?
- Open Codex App 26.810.52044 on macOS.
- Run a task that invokes
spawn_agent with arguments that fail tool validation.
- Allow the model to correct the arguments and retry until one subagent is successfully created.
- Inspect the activity transcript.
- Observe that rejected attempts remain displayed as Creating an agent alongside the one successful Created an agent event.
The captured reproduction used one invalid agent_type/fork_context combination, one invalid inherited model identifier, and then one corrected successful call.
What is the expected behavior?
Rejected spawn_agent attempts should be rendered as failed, or collapsed into an explicit retry/error state. A successful subagent should produce one clearly identified Created an agent entry keyed by its call or agent ID. Validation retries should not look like multiple successful agent spawns.
Additional information
Only one agent instance was actually created in this reproduction; this is a Codex App transcript/lifecycle presentation bug.
This may be adjacent to #36206 and #37831, but those issues describe duplicate TUI activity events. This report specifically covers failed spawn_agent validation attempts remaining visually stuck as ongoing/duplicate creation activity in the desktop App.
A screenshot is attached with sensitive local path segments blurred while preserving the similar retry inputs that demonstrate the misleading duplicate-agent presentation.
What version of the Codex App are you using (From “About Codex” dialog)?
26.810.52044 (build 6662)
What subscription do you have?
Managed work account (exact subscription tier is not displayed in the App)
What platform is your computer?
Darwin 25.5.0 arm64 arm
What issue are you seeing?
The Codex App activity transcript can make a single successfully created subagent look as if it was spawned multiple times.
In this reproduction, exactly one explorer agent was created successfully. Before that success, two spawn_agent calls were rejected during parameter validation:
Full-history forked agents inherit the parent agent type; omit agent_type, or spawn without a full-history fork.Unknown model openai.gpt-5.6-sol for spawn_agent. Available models: gpt-5.6-sol.The App retained the two rejected calls as separate expanded Creating an agent cards instead of marking them failed. This makes the transcript look like duplicate successful spawns even though only one agent instance was created. The two cards contain slightly different retry inputs, confirming this is misleading lifecycle rendering rather than duplicate backend creation.
What steps can reproduce the bug?
spawn_agentwith arguments that fail tool validation.The captured reproduction used one invalid
agent_type/fork_contextcombination, one invalid inherited model identifier, and then one corrected successful call.What is the expected behavior?
Rejected spawn_agent attempts should be rendered as failed, or collapsed into an explicit retry/error state. A successful subagent should produce one clearly identified Created an agent entry keyed by its call or agent ID. Validation retries should not look like multiple successful agent spawns.
Additional information
Only one agent instance was actually created in this reproduction; this is a Codex App transcript/lifecycle presentation bug.
This may be adjacent to #36206 and #37831, but those issues describe duplicate TUI activity events. This report specifically covers failed spawn_agent validation attempts remaining visually stuck as ongoing/duplicate creation activity in the desktop App.
A screenshot is attached with sensitive local path segments blurred while preserving the similar retry inputs that demonstrate the misleading duplicate-agent presentation.