spawn_agent(model="gpt-5.4-mini") produces child thread metadata with model="gpt-5.4" #15177

Activity

1. himwichboys

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Mar 19, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   tool-callsIssues related to tool callingIssues related to tool calling

   on Mar 19, 2026
3. github-actions commented on Mar 19, 2026

   

   github-actionsbot

   on Mar 19, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • spawn_agent should preserve explicit model overrides for explorer agents #15170
   • Subagent Custom Agent Model/Reasoning Config Not being Respected #14671
   • Sub-agent role top-level reasoning settings are overridden by inherited parent profile #13849

   Powered by Codex Action
4. jhste102lab commented on Mar 27, 2026

   

   jhste102lab

   on Mar 27, 2026

   More actions

   I can still reproduce this on current main (be5afc65d31728c11d67c589cebbc64a87979e74) in the CLI, not just in Desktop/VS Code.

   What I verified on March 27, 2026:

   • Built Codex locally from source at be5afc6
   • Ran a minimal codex exec repro that spawns exactly one explorer
   • Parent spawn_agent call explicitly requested:
     • agent_type: "explorer"
     • model: "gpt-5.4-mini"
     • reasoning_effort: "xhigh"
   • Spawned child session was created successfully and completed its task

   But the persisted child session metadata still records the inherited/default model instead of the requested explorer override:

   • Parent session: 019d2d8c-eef0-7f03-baa3-6aa4605e3afe
   • Child session: 019d2d8d-2697-76d0-99fa-ac765ee8db15

   Observed in the logs:

   Parent session:

   {"type":"function_call","name":"spawn_agent","arguments":"{\"agent_type\":\"explorer\",\"fork_context\":false,\"model\":\"gpt-5.4-mini\",\"reasoning_effort\":
   \"xhigh\",...}"}
   
   Child session turn_context:
   
   {
     "model": "gpt-5.4",
     "collaboration_mode": {
       "mode": "default",
       "settings": {
         "model": "gpt-5.4",
         "reasoning_effort": "medium"
       }
     },
     "effort": "medium"
   }
   
   So at minimum, this is still a child-session metadata / provenance bug on current main.
   
   I still cannot prove from logs alone whether actual inference ran on gpt-5.4-mini and only the metadata is wrong, or whether the override is being lost before
   execution. But the persisted child metadata is definitely inconsistent with the parent spawn_agent request.
   
   This seems broader than the original desktop-only framing, since I reproduced it in codex exec on a source build from current main.
   
   If useful, I can provide a more compact minimal repro prompt/command shape as well.

   👍React with 👍2Reacted by Talha Sarı and Maksim Peterburgskiy
5. ambrosino-oai

   removed

   tool-callsIssues related to tool callingIssues related to tool calling

   on Mar 30, 2026
6. ozan-s commented on Apr 4, 2026

   

   ozan-s

   on Apr 4, 2026

   More actions

   I'm also seeing sub-agents ignore the model I request. When I spawn with model: "gpt-5.4-mini", the agent runs on the parent's model ("gpt-5.4") instead.

   This only happens with the "explorer" agent type. The "explorer" role has an associated config file (explorer.toml) that triggers a full config rebuild during spawn. That rebuild preserves model_provider but not model, so the requested model is lost and falls back to the parent session's model. The "default" role has no config file, so it skips the rebuild entirely and respects the model you specify.

   Workaround: Use "default" as the agent type instead of "explorer". The model selection will then work as expected.

   Here is the proof:

   › Launch three agents, one for each type with a dummy request (read only). Launch them all with gpt-5.4-mini high reasoning.
   
   • Using the requested setup now: I’ll spawn three subagents in parallel (default, explorer, worker), each with a read-only dummy task, all on gpt-5.4-mini with high reasoning.
   
   • Spawned Bohr [default] (gpt-5.4-mini high)
     └ Dummy read-only task: inspect repository root and report the first 10 top-level entries. Do not modify any files or run destructive commands.
   
   • Spawned Tesla [explorer] (gpt-5.3-codex medium)
     └ Dummy read-only task: find AGENTS.md files in this workspace and return their paths only. Read-only; do not modify files.
   
   • Spawned Pasteur [worker] (gpt-5.4-mini high)
     └ Dummy read-only task: run a safe read-only check (`git status --short`) and report output summary. Do not edit files, stage changes, or run destructive comma...
   
7. ozan-s commented on Apr 4, 2026

   

   ozan-s

   on Apr 4, 2026

   More actions

   And here is the proposed fix:

   ⏺ Root Cause Identified
   
     The bug is an ordering issue in the spawn handler. Both V1 and V2 have the same problem.
   
     The exact flow (both multi_agents/spawn.rs and multi_agents_v2/spawn.rs):
   
     1. build_agent_spawn_config — creates config with config.model = parent_model (e.g., "gpt-5.4") — multi_agents_common.rs:226
     2. apply_requested_spawn_agent_model_overrides — sets config.model = "gpt-5.4-mini" (what you requested) — multi_agents_common.rs:298
     3. apply_role_to_config — rebuilds the entire Config from scratch using the config layer stack — role.rs:69
   
     Why the model gets lost:
   
     apply_role_to_config calls build_next_config which rebuilds the config from layers. Inside reload::reload_overrides (role.rs:253-262), the function preserves cwd and model_provider, but does NOT preserve model:
   
     fn reload_overrides(config: &Config, preserve_current_provider: bool) -> ConfigOverrides {
         ConfigOverrides {
             cwd: Some(config.cwd.to_path_buf()),
             model_provider: preserve_current_provider.then(|| config.model_provider_id.clone()),
             // model is NOT preserved! Falls back to Default::default() → None
             ..Default::default()
         }
     }
   
     Then in Config::load_config_with_layer_stack (mod.rs:2440):
     let model = model.or(config_profile.model).or(cfg.model);
     //          ^^^^ None (from overrides) → falls through to profile/global config model → "gpt-5.4"
   
     So the requested "gpt-5.4-mini" set in step 2 is wiped out by the config rebuild in step 3, and the agent inherits the parent's model from the config layers.
   
     Why it only affects certain agent types:
   
     The "default" role has config_file: None, so apply_role_to_config_inner returns early without rebuilding. But "explorer" has config_file: Some("explorer.toml") — even though the file is empty, the rebuild still
     runs and wipes the model override.
   
     Fix
   
     The fix is to swap the order: apply the model override AFTER the role config rebuild.
   
     In both multi_agents/spawn.rs and multi_agents_v2/spawn.rs, change from:
   
     apply_requested_spawn_agent_model_overrides(...)?;  // Sets requested model
     apply_role_to_config(&mut config, role_name)?;       // Rebuilds config, LOSES the model
   
     To:
   
     apply_role_to_config(&mut config, role_name)?;       // Rebuilds config first
     apply_requested_spawn_agent_model_overrides(...)?;    // THEN set requested model
   
8. ambrosino-oai

   added

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Apr 25, 2026
9. Keesan12 commented on May 18, 2026

   

   Keesan12

   on May 18, 2026

   More actions

   Even if inference is actually running on mini, the metadata mismatch is still a real bug because cost and behavior analysis depend on the persisted receipt, not just the hidden execution path. I would treat this as provenance, not cosmetics: requested model, resolved model, displayed model, and actual execution model should either match or be shown explicitly when they do not. We ended up needing that exact split in MartinLoop once fan-out comparisons got more cost-sensitive.
10. ambrosino-oai

    closed this as duplicateon Jun 22, 2026