spawn_agent ignores requested gpt-5.4-mini model and launches subagent as gpt-5.4

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

• #15177
• #15501
• #15170
• #16371

Powered by Codex Action

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...

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

I can still reproduce this locally, and in my case it looks like more than just metadata/UI drift.

Environment:

• Codex TUI on Linux
• observed on 2026-04-07
• parent session model: gpt-5.4

Minimal repro:

• spawn one trivial subagent with:
• agent_type: "explorer"
• model: "gpt-5.4-mini"
• reasoning_effort: "medium"
• fork_context: false
• message: Run exactly one trivial command: sleep 5. Then report only done.

Observed TUI:

• Codex immediately showed:
• Spawned Euclid [explorer] (gpt-5.4 medium)

Observed local runtime logs (codex-tui.log):

• parent spawn path recorded:
• thread_spawn ... model=gpt-5.4
• get_model_info{model="gpt-5.4"}
• child thread also ran with:
• turn ... model=gpt-5.4

Child thread id from this repro:

• 019d68b7-81f6-7b43-be8b-4f504ef496d8

This makes it look like the explicit gpt-5.4-mini request is not merely displayed incorrectly; the spawned explorer thread appears to actually initialize and execute as gpt-5.4.

That matches the theory above that the explorer role config rebuild is wiping the requested model and falling back to the parent model.

Also confirmed from the same local logs:

• genuine mini runs elsewhere are explicitly logged as model=gpt-5.4-mini
• so in this environment, the logger does know how to distinguish mini correctly

Impact:

• this makes cost-sensitive delegation unreliable
• if the UI/log says gpt-5.4 medium, users are likely paying for full gpt-5.4 even though they explicitly requested gpt-5.4-mini

I attached:

• a short TUI snippet
• a sanitized local log excerpt

log-excerpt.txt
tui-evidence.txt

bump, this bug prevents Codex being an option in heavy token consuming environment (typical for any mid/large size company).

I can reproduce a related model-proof/model-routing failure on a newer Codex build, with 5.3 models rather than only 5.4-mini.

Environment:

• Codex CLI: 0.128.0-alpha.1
• Parent/global model: gpt-5.5
• Parent/global reasoning: high
• Requested child models: gpt-5.3-codex and gpt-5.3-codex-spark

Observed behavior:

• A full-history fork plus explicit model override route was rejected/unsupported.
• Retrying with self-contained assignments allowed model-specific requests to be attempted.
• The child work completed, but child final reports self-reported the active parent/global model (gpt-5.5) rather than proving the requested gpt-5.3-codex or gpt-5.3-codex-spark route.
• A direct codex exec --model gpt-5.3-codex-spark --json probe can request the Spark route, but final generated text still cannot directly observe the actual runtime model. In other words, final prose is not reliable model identity proof.

Expected behavior:

• A spawned subagent should either run using the requested model and expose reliable launcher/runtime metadata, or fail early with an explicit "model override unsupported" reason.
• The parent UI/logs and child metadata should expose the actual child runtime model.
• Generated child prose should not be the only place where model identity is inferred.

Impact:

• Model-specific second-voice workflows are unreliable.
• Users cannot tell whether requested cheaper/faster/specialized subagent routes were honored.
• This affects cost control, review quality, and auditability.

This looks related to the same class of issue tracked here: requested subagent model selection is ignored, overwritten, or not provable after orchestration.