GPT-5.6 Sol root exposes spawn_agent without agent_type, blocking custom agent routing

Resolved 💬 9 comments Opened Jul 13, 2026 by pax-k Closed Jul 16, 2026

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

Summary

When a Codex task is rooted on GPT-5.6 Sol, the available multi-agent spawn schema can omit agent_type. That prevents custom-agent routing from selecting configured agents, even when the same custom agents work from a root runtime that exposes stable multi_agent_v1.spawn_agent(agent_type=...).

Expected behavior

A GPT-5.6 Sol root should expose a spawn contract that can select a configured custom agent, for example:

{
  "agent_type": "gpt56_router_terra_explorer",
  "task_name": "bounded exploration task",
  "message": "...",
  "fork_turns": "none"
}

or the stable v1 equivalent:

{
  "agent_type": "gpt56_router_terra_explorer",
  "fork_context": false,
  "message": "..."
}

Observed behavior

In the failing GPT-5.6 Sol-rooted tasks, the spawn schema appears to provide only fields like:

task_name
message
fork_turns

There is no agent_type field. Supplying a custom agent name through task_name only names the child task; it does not select the configured custom agent.

Why this matters

This blocks model-pinned custom-agent routing. A router skill cannot safely delegate to configured roles such as:

gpt56_router_luna_worker pinned to gpt-5.6-luna
gpt56_router_terra_explorer pinned to gpt-5.6-terra
gpt56_router_sol_debugger pinned to gpt-5.6-sol

Without agent_type, the parent cannot select the role-specific TOML configuration, sandbox defaults, model, or reasoning effort.

Working comparison

In a current non-GPT-5.6-Sol-rooted runtime, the callable spawn tool is multi_agent_v1.spawn_agent and includes agent_type and fork_context. Using that schema, the same router successfully spawned:

agent_role: gpt56_router_terra_explorer
model: gpt-5.6-terra
effort: medium
ok: true

The persisted child metadata confirmed the selected custom agent and pinned model.

Requested fix

Please expose custom-agent selection for GPT-5.6 Sol-rooted tasks, either by:

adding agent_type to the GPT-5.6 Sol multi-agent v2 spawn schema, or
routing GPT-5.6 Sol-rooted tasks through the stable v1 spawn schema when custom agents are available.

The key requirement is that task_name remains only a descriptive child-task identifier and does not need to be overloaded as a role selector.

Additional validation note

On the client/plugin side, we hardened our inspector to fail if the child role matches but the child model does not match the configured pinned model. That catches the case where a runtime accepts the role name but silently runs the root model instead.

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 7 days ago

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

#31893
#32587
#32291
#32703
#32705

Powered by Codex Action

gabimoncha · 6 days ago

up pls

FRITS-Kh · 6 days ago

I can reproduce this from a gpt-5.6-sol-rooted Codex session in VS Code Remote.

Environment:

Codex VS Code extension: openai.chatgpt 26.707.71524 (linux-x64)
Bundled CLI: codex-cli 0.144.2; the codex command resolves to the extension-bundled executable
VS Code Server: 1.128.0 (x64), in a Remote session; this is the server-side version, not a verified desktop-client version
Root model: gpt-5.6-sol

The project contained a valid standalone researcher profile. Relevant excerpt (the file also contains description and developer_instructions):

# .codex/agents/researcher.toml
name = "researcher"
model = "gpt-5.6-terra"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

The project also had a reviewer profile configured for gpt-5.6-sol.

I gave the root agent this prompt:

Diagnostic only. Do not modify files. Delegate to the researcher reading package.json and reporting the package name. Then delegate to the reviewer independently confirming that result. Wait for both agents and report which agent types were used.

The exposed spawn_agent schema accepted only:

task_name
fork_turns
message

There was no agent_type or other named-profile selector. The root therefore made generic child-task calls named researcher_package_name and reviewer_package_name, with the intended roles described only in message text.

The researcher child used gpt-5.6-sol, not the gpt-5.6-terra configured in the researcher profile. Its task_name became only the child task/path name; it did not select the named profile.

The reviewer child also used Sol, but that is not independent evidence of role routing because both the reviewer profile and the root were configured for Sol.

Expected:

The orchestrator can explicitly select the named researcher profile.
The child applies that profile, including its model, reasoning effort, sandbox, and instructions.
The reviewer can be selected independently for confirmation.

Actual:

No named-agent selector was exposed.
task_name and prompt text did not bind a configured profile.
The Terra-configured researcher ran with the Sol root model.

This is evidence of a role-resolution gap, not only a per-spawn model-override gap. #32749 exposes model and reasoning_effort for V2 spawns, which can help choose a model per child, but it does not restore selection of a named agent profile or apply that profile’s instructions and sandbox configuration.

nicholasjkershaw-arch · 6 days ago

Additional reproduction from an independent integration diagnosis involving a third-party runtime harness. I am not affiliated with OpenAI or the Codex project.

Environment

Codex stable: 0.144.4
Codex alpha: 0.145.0-alpha.11
Root model: gpt-5.6-sol
Linux x86_64, CLI non-interactive capability probes

Observed schema

On stable, the callable spawn_agent schema exposed only:

task_name
message
fork_turns

On alpha, it additionally exposed model and reasoning_effort, but still did not expose agent_type or another configured-agent selector.

task_name remained the canonical child task/path identifier. It did not select an installed custom-agent TOML or apply the configured role instructions/model.

Additional diagnostic

I ran a one-process, nonpersistent alpha probe with MultiAgentV2 metadata visibility enabled:

features.multi_agent_v2 = {
  enabled = true,
  hide_spawn_agent_metadata = false,
  expose_spawn_agent_model_overrides = true
}

The request was rejected before model execution:

Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.

This was only a diagnostic override, not a proposed persistent workaround.

Public-source observation

At public source commit 69acc71cb18fc9a1b7858f92489cc8d135e450f2:

multi_agents_v2/spawn.rs already parses optional agent_type and calls apply_role_to_config.
multi_agents_spec.rs removes agent_type when hide_agent_type_model_reasoning is true.
config/mod.rs defaults hide_spawn_agent_metadata to true.

References:

Inference, not confirmed root cause

The client implementation appears capable of applying a named role, while the model-reserved tool schema rejects exposing that selector. This may require the reserved server/model tool schema and client-generated schema to be aligned, rather than only changing the local handler.

The important semantic requirement is that task_name remain descriptive and that configured-agent selection be explicit, so the selected TOML role, instructions, model, reasoning effort, and sandbox can be verified independently.

No application or project-specific data was used in this reproduction.

Attribution and prior work

This reproduction arose while diagnosing oh-my-codex (OMX), an independent third-party runtime harness that is not affiliated with OpenAI.

OMX issue #3118, opened by @arikon and investigated by @Yeachan-Heo, had already identified the native spawn_agent capability-contract mismatch and the need to avoid presenting task_name as native role selection. That prior work materially informed the framing of this reproduction.

Authorship disclosure: this comment was submitted by @nicholasjkershaw-arch with assistance from OpenAI Codex. The follow-up version probes, public-source inspection, and evidence-versus-inference synthesis were performed through Codex and checked against the installed binaries and linked public repositories. OMX supplied the runtime context and prior investigation; it is not being represented as affiliated with or part of Codex.

maizaAvaro · 6 days ago

Additional post-#32749 configured-profile evidence:

Configuration under test:

registered ralph-architect profile: gpt-5.5 / high
normalized developer-instruction body: 7,216 bytes
SHA-256: 3181f9717ec96043519ac43c8c961364ffbaf9693301946177a75f0923ea9e85

Fresh V1 positive control (CLI v0.141.0):

exact-version package runner with root pinned to gpt-5.5/high
spawn_agent used agent_type: ralph-architect and fork_context: false
child recorded agent_role: ralph-architect
configured gpt-5.5/high was applied
expected developer body: 1 expected / 1 exact match across five heterogeneous developer items

Post-#32749 V2 comparison (CLI v0.145.0-alpha.7):

the release contains #32749
the live V2 schema exposed optional manual model and reasoning_effort fields but no agent_type
the call tested named-profile behavior via task_name with fork_turns: none, without manually repeating the profile values
child recorded agent_role: null
configured gpt-5.5/high was not applied; the child inherited root gpt-5.6-sol/xhigh
the configured developer body had zero exact or containment matches across seven developer items

Conclusion: #32749 restores a manual per-spawn override channel. It does not restore selection of a registered [agents.<role>] profile, automatic application of that profile's model/effort, or injection of its developer instructions. The v0.145 run does not test whether manual overrides work; it shows that named-profile resolution still fails. Manually duplicating two runtime fields is not configured-agent parity.

maizaAvaro · 6 days ago

Separate product-contract request for configured-agent parity:

Even if MultiAgent V2 intentionally keeps instruction bodies opaque, could the persisted/runtime contract expose an authenticated effective-profile receipt containing:

requested profile ID and effective agent/profile ID;
effective model and reasoning effort;
effective sandbox plus approval/permission profile;
effective tool policy;
developer-instruction/config SHA-256 or immutable revision ID;
delegated task delivery identity/hash as a separate field;
completed child metadata carrying effective—not only requested—values.

An end-to-end regression test should register one real [agents.<role>] profile with distinctive instructions, runtime values, and isolation policy; select it through the model-visible V2 spawn tool; and assert the complete effective envelope. A schema test for optional model and reasoning_effort inputs does not certify profile resolution or developer-payload application.

This would let downstream systems verify configured-agent receipt without logging instruction bodies.

pax-k · 5 days ago

Consolidated diagnosis: this is a MultiAgentV2 capability-contract regression

After reviewing this issue, its duplicate set (#31893, #32587, #32291, #32703, and #32705), the related component reports, the current documentation, and current public source, the evidence points to one central failure rather than invalid custom-agent TOML or insufficient prompt steering.

Environment for this reproduction

Platform: macOS
Standalone CLI: 0.144.4
Desktop embedded engine: 0.144.2
Current task runtime: 0.144.2
ChatGPT app: 26.707.72221 (build 5307)

The standalone CLI version is not the Desktop runtime version in this environment. Updating the standalone binary therefore does not change the engine or tool schema used by an already-running Desktop task.

Root problem

The documented custom-agent configuration layer and the GPT-5.6 / MultiAgentV2 model-visible spawn_agent contract are disconnected.

Current V2 client code can parse agent_type and apply the selected role configuration through apply_role_to_config. However, the default hide_spawn_agent_metadata = true behavior removes agent_type from the model-visible schema. Despite its name, this setting removes a functional routing input, not merely display or response metadata.

That leaves the model with fields such as:

task_name
message
fork_turns

and, after #32749, potentially:

model
reasoning_effort

but still no configured-agent selector.

task_name is only the canonical child task/path identifier. It does not resolve a custom agent by name. Prompt text cannot compensate for a missing structured selector. The resulting child can complete successfully while recording:

agent_role = null
model/effort = inherited from the parent, or manually overridden

and without applying the configured agent's full instructions and configuration layer.

This explains why V1 controls work with the same agent files: V1 exposes agent_type, so the role resolver is reachable. The problem is therefore not custom-agent discovery itself; it is the default V2 tool surface and its backend contract.

Why #32749 is only a partial fix

PR #32749 restores manual per-spawn model and reasoning_effort overrides. That is useful, but it is not custom-agent parity.

It does not restore:

named profile selection;
agent_role identity;
automatic application of the profile's model and effort;
developer_instructions;
profile-specific MCP, skills, tool, and other configuration;
a verifiable effective-profile receipt.

Manually copying two profile values into a generic spawn is not equivalent to selecting the configured agent.

Compounding V2 problems

The missing selector interacts with several other defaults:

Model catalog metadata can force V2 even when the local V2 feature flag is disabled. An explicit user/runtime choice does not currently win.
Setting only hide_spawn_agent_metadata = false can trigger the reserved-schema error for collaboration.spawn_agent, because the locally expanded schema does not match the backend-reserved schema.
Omitted fork_turns defaults to all, while full-history forks reject agent_type, model, and reasoning overrides. Merely exposing the fields would still leave the natural override call shape broken.
The spawn path reapplies the parent's live permission profile after applying the role, so a role configured as read-only can become full-access under a full-access parent.
Silent generic fallback makes the problem difficult to detect unless persisted child metadata is inspected. Child self-report is not sufficient runtime proof.

Expected behavior

The V2 tool should expose distinct role and task identity:

{
  "agent_type": "researcher",
  "task_name": "inspect_auth_flow",
  "message": "Inspect the authentication flow and report findings.",
  "fork_turns": "none"
}

with these semantics:

agent_type -> selects and resolves the configured agent
 task_name -> names this particular child task/thread
 message   -> supplies the delegated task
 fork_turns -> controls inherited conversation history

Selecting an agent should apply its complete configuration layer: role identity, developer instructions, model, reasoning effort, MCP/skills/tool configuration, and permission defaults. An unknown or unavailable agent should fail explicitly rather than silently spawning a generic agent_role = null child.

Proper fix

Add agent_type to the default server-approved GPT-5.6/MultiAgentV2 reserved schema. Release the backend schema and client-generated schema together.
Make hide_spawn_agent_metadata control returned/display metadata only. It must not remove functional routing inputs.
Keep task_name descriptive and separate from configured-agent selection.
Define deterministic precedence:

parent base configuration
  -> selected custom-agent configuration
  -> explicit per-spawn model/effort/service-tier overrides
  -> live security constraints

Merge permissions monotonically: a child may become more restrictive than the parent, such as read-only, but must not become less restrictive without the normal approval/policy path.
If agent_type, model, or reasoning_effort is supplied and fork_turns is omitted, default to a context-free or documented bounded fork. Continue rejecting an explicitly requested full-history fork with heterogeneous overrides.
Treat model-catalog multi_agent_version as a default. An explicit user or managed runtime choice should win. Until V2 has custom-agent parity, GPT-5.6 should not force users away from the working V1 role-routing path.
Return effective child metadata: resolved agent/profile ID, model, effort, permission profile, and ideally an immutable configuration revision/hash.

Required product-level regression test

Using an empty Codex home and the normal shipped model catalog:

Register a Terra/medium/read-only researcher and a Sol/high/read-only reviewer.
Start a GPT-5.6 Sol root.
Spawn both through the exact model-visible reserved tool schema.
Assert effective role, developer instructions, model, effort, permissions, task delivery, and completed metadata.
Run the same contract through CLI, Desktop/app-server, and IDE surfaces.
Repeat with V2 explicitly disabled and assert that the explicit runtime selection wins.

Until that end-to-end test passes on the exact schema shipped to users, the safe release behavior is to stop forcing V2 for GPT-5.6 or fall back to V1 when configured-agent selection is required.

In short: GPT-5.6 currently forces a V2 runtime whose default reserved schema prevents the model from reaching the existing custom-agent resolver. The complete fix is an explicit backend-supported agent_type selector plus correct fork, configuration-precedence, permission, observability, and runtime-selection semantics.

cc @jif-oai @bolinfest @aibrahim-oai @viyatb-oai @etraut-openai @shijie-oai @pakrym-oai @owenlin0

ictechgy · 5 days ago

Additional sanitized confirmation

Reproduced on macOS arm64 with Codex CLI 0.144.4 and a temporary, non-installed 0.145.0-alpha.14 run.

A schema-only codex exec --ignore-user-config probe enabled multi_agent, multi_agent_v2, and use_agent_identity; no child was spawned.

Stable exposed: task_name, message, fork_turns.
Alpha additionally exposed: model, reasoning_effort.
Neither exposed agent_type or an equivalent named-profile selector.

Repeating the stable probe with terminal/tmux environment markers unset produced the same schema, so that compatibility layer was not the differentiator.

A separate prior run confirmed the impact: children given Architect- and Critic-descriptive task names completed, while persisted native metadata recorded agent_role: null. task_name named the child task but did not select a configured role.

Expected: explicit configured-agent selection in the model-visible schema and persisted effective-role metadata. No private or project-specific data is included.

jif-oai contributor · 4 days ago

This will land soon. I merged the discussions here: https://github.com/openai/codex/issues/31814#issuecomment-4991048945