Codex Desktop subagents ignore model and reasoning settings. CAN YOU FIX THIS AT LAST?

Open 💬 5 comments Opened Jun 17, 2026 by Nickonomic

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

Codex Desktop subagents ignore requested model and reasoning settings and appear to inherit the parent thread settings instead.

This is not just a child-agent self-introspection problem. The Codex Desktop subagent window itself shows the child running with the parent model/reasoning.

Can you fix this at last? This has been reported in multiple forms before, and it makes subagents unreliable for any workflow that depends on model or reasoning separation.

Environment

Product: Codex Desktop App
Codex Desktop version: 26.609.41114
Electron version: 42.1.0
Subscription: Pro 20x
Parent visible setting: 5.5 Extra High

Steps to reproduce

Start a Codex Desktop thread using gpt-5.5 with Extra High reasoning.
Ask Codex to spawn two subagents with different settings:

Subagent A:
model: "gpt-5.5"
reasoning_effort: "xhigh"
Subagent B:
model: "gpt-5.3-codex-spark"
reasoning_effort: "low"

Open the spawned subagent tabs/windows in Codex Desktop.
Inspect the displayed model/reasoning in each child subagent.

Actual behavior

Both subagents show the parent settings:

Subagent A, Copernicus, requested gpt-5.5 / xhigh, showed 5.5 Extra High.
Subagent B, Nash, requested gpt-5.3-codex-spark / low, also showed 5.5 Extra High.

The spawn tool accepted the settings, but the child Desktop session did not reflect them.

Observed IDs from the repro:

Copernicus: 019ed571-fb13-7602-b5f7-12e2e3f117d0
Nash: 019ed572-102f-7660-a767-f7dd7c6466fb

Expected behavior

A child spawned with:

{
  "model": "gpt-5.3-codex-spark",
  "reasoning_effort": "low"
}

should run and display as gpt-5.3-codex-spark with low reasoning, not inherit the parent thread's gpt-5.5 Extra High settings.

If model/reasoning selection for subagents is not supported in Codex Desktop, the UI/tool should reject or clearly ignore those settings instead of silently accepting them.

Why this matters

This makes subagent model selection unreliable. Users cannot safely use lower-cost or lower-latency subagents for simple parallel work, because the UI shows they may actually be running under the parent high-capability/high-reasoning settings.

That affects:

cost-sensitive fan-out
latency-sensitive subagent workflows
reproducibility of agent behavior
trust in subagent configuration

Related issues

This appears related to, but not fully resolved by, previous reports:

#14671
#15501
#16548
#22250
#27624

Some of those mention custom agent config, per-spawn settings, metadata/display issues, or CLI/TUI behavior. This repro is specifically for Codex Desktop where the child subagent UI itself shows the parent settings.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

#27624
#27061

Powered by Codex Action

bnjmnrsh · 2 months ago

can confirm - this is becoming an expensive problem.

MercadoFabio · 2 months ago

I can reproduce this on Codex Desktop.

Parent visible setting:

gpt-5.5
reasoning: low

Spawn request sent by the main agent:

{
  "agent_type": "gateway-agent",
  "model": "gpt-5.4-mini",
  "reasoning_effort": "medium",
  "message": "Smoke test only..."
}

Local audit confirms the spawn request was accepted with the requested override:

{
  "spawn_agent_type": "gateway-agent",
  "spawn_model": "gpt-5.4-mini",
  "spawn_reasoning_effort": "medium",
  "spawn_model_issue": ""
}

But the Codex Desktop child subagent UI shows 5.5 Low, matching the parent thread instead of the requested child settings.

This is not agent self-introspection: the Desktop UI itself displays the inherited parent model/reasoning. The subagent completed successfully, but the displayed model/reasoning contradicts the accepted spawn_agent request.

CalmProton · 1 month ago

I am seeing a related limitation in Codex Desktop on Windows. The local Codex model catalog reports client version 0.144.2.

I created project-scoped custom agents under .codex/agents/ with explicitly pinned models and reasoning levels:

cheap-worker: gpt-5.6-luna, medium
cheap-explorer: gpt-5.6-luna, medium
medium-worker: gpt-5.6-terra, medium
smart-worker: gpt-5.6-sol, high

The custom-agent TOML configuration is valid, but the spawn_agent tool exposed to the parent agent in this task accepts only task_name, message, and fork_turns. It provides no agent_type, profile, model, or reasoning_effort parameter.

This means the orchestrator cannot deterministically select one of the configured agents or verify that cost-sensitive routing was honored. Natural-language routing instructions in AGENTS.md are not an enforceable substitute for an explicit tool parameter.

Expected behavior:

Expose an agent_type or profile parameter in spawn_agent.
Optionally expose per-spawn model and reasoning_effort overrides.
Honor the selected custom-agent TOML configuration.
Return the actual child model and reasoning level in spawn results and runtime metadata.
Reject unsupported overrides instead of silently inheriting parent configuration.

The practical impact is that inexpensive parallel exploration cannot be reliably separated from expensive parent-agent reasoning.

janneskruse · 23 days ago

I am also getting this problem when trying to launch gpt-5.3-codex-spark or gpt-5.3-codex-spark-preview as a subagent. In both the ChatGPT App and in the VS Code extension I can select gpt-5.3-codex-spark but once I want to orchestrate from my main agent, it says that gpt-5.3-codex-spark isn't exposed and only Sol and Terra are. Luna isn't available neither.

Is there any configuration I am missing? I am on the Pro plan and using ChatGPT/Codex version 26.802.11031