MultiAgentV2 is fundamentally broken as a forced runtime and should not be imposed by model metadata
Summary
MultiAgentV2 may be reasonable as an experimental or explicitly enabled runtime. It is not currently viable as a runtime that the model catalog can force on users.
gpt-5.6-sol selects MultiAgentV2 through model metadata even when the local features.multi_agent_v2 flag is disabled. Under the vanilla V2 configuration, Sol cannot reliably perform the obvious intended workflow: orchestrating heterogeneous Terra/Luna or named role-specific subagents with different models, reasoning efforts, and permissions.
This is an umbrella integration/release-policy issue. Individual symptoms have already been reported, but their interaction leaves no supported vanilla path for the intended workflow.
The default failure chain
- The model catalog overrides the user's runtime selection. A model with
multi_agent_version = "v2"selects V2 even whenFeature::MultiAgentV2is explicitly disabled. This behavior is deliberately covered byremote_multi_agent_selector_overrides_feature_flags. - V2 hides the routing controls by default.
hide_spawn_agent_metadata = trueremovesagent_type,model,reasoning_effort, andservice_tierfrom the model-visiblespawn_agentschema. Despite its name, this setting removes functional inputs, not merely metadata from output. - Omitted
fork_turnsdefaults toall. Therefore the natural/default spawn is a full-history fork. - Full-history forks reject heterogeneous routing. V2 rejects
agent_type,model, andreasoning_effortoverrides for a full-history fork and requires them to inherit from the parent. task_nameis not a role selector. Naming a task after a configured[agents.<role>]entry only creates an agent path; it does not select that role. The child can silently recordagent_role = nulland inherit Sol.- Role-specific sandboxing is overwritten by the parent's live permission profile. The spawn path applies the role and then copies the parent turn's permission profile onto the child. In particular, a full-access parent cannot create a genuinely read-only role-defined child through this path.
- The apparent config workaround may collide with the server-reserved schema. Exposing the hidden fields under the default
collaboration.spawn_agentnamespace has been observed to fail before inference because the declared schema does not match the reserved backend schema. Changing the namespace is an undocumented, version-sensitive workaround.
The result is a circular contract:
- the catalog forces V2;
- V2's default schema hides the controls needed for heterogeneous agents;
- its default fork mode forbids those controls anyway;
- named roles are not selectable through
task_name; and - role-defined isolation is replaced with the parent's permissions.
At that point MultiAgentV2 is not merely rough around the edges. For the intended Sol orchestrator workflow, the vanilla product configuration is internally contradictory.
Reproduction
- Use Codex CLI
0.144.xwith ChatGPT authentication and a clean/default configuration. - Start a fresh task using
gpt-5.6-sol. - Observe that the model-selected runtime is V2 even if the local V2 feature is disabled.
- Inspect the visible
spawn_agentschema. On affected configurations it exposes onlytask_name,message, andfork_turns, notagent_type,model,reasoning_effort, orservice_tier. - Register a role such as:
[agents.research_analyst]
description = "Read-only documentation and research specialist."
config_file = "agents/research-analyst.toml"
with:
model = "gpt-5.6-terra"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
- Ask Sol to spawn that role. Using
task_name = "research_analyst"creates only the path/name. - Inspect the effective child configuration/rollout metadata. The affected behavior is
agent_role = null, parent Sol model/effort, and the parent's permission profile. - If the hidden arguments are exposed or supplied, omit
fork_turnsand observe that the default full-history fork rejects the override.fork_turns = "none"is required, but this is not the default and does not repair the role-specific sandbox overwrite.
Existing component reports
- #31097 — model metadata forces V2 despite local configuration
- #31814 — Sol/V2 hides the model and role routing controls
- #32031 — hidden controls plus the default full-history call shape
- #20077 —
fork_turnsdefaults to full history and rejects overrides - #31864 and #32674 — reserved namespace/schema incompatibility
- #32587 and #32703 — named roles silently become generic inherited children
- #32504 — effective child identity/model/effort is not reliably surfaced
These issues are related, but fixing any one in isolation does not produce a working vanilla Sol → Terra/Luna role-routing path.
Expected behavior
A model-catalog entry must not be able to remove a user's working runtime without providing an equivalent, tested workflow.
At minimum:
- Treat the catalog's
multi_agent_versionas a default, not an override of an explicit user selection. - Remove the forced V2 selector from Sol/Terra until the complete clean-install workflow passes end to end.
- Expose
agent_type,model,reasoning_effort, andservice_tierin a backend-compatible schema. - Default
fork_turnstonone, or make explicit role/model overrides compatible with omitted/full-history forking. - Keep
task_nameand role selection distinct and expose a real role selector. - Allow a child to adopt a stricter permission profile than its parent, including a read-only role under a full-access parent. Less-restrictive escalation can continue to require the normal approval/policy checks.
- Record and display the effective child role, model, effort, and permission profile—not merely requested values.
Required regression test
Please add one product-level test using an empty Codex home and the normal model catalog:
- Select Sol.
- Register a Terra/medium/read-only role and a Luna/low/read-only role.
- Spawn both through the exact model-visible tool schema.
- Assert their effective model, effort, role, permission profile, task delivery, and completed metadata.
- Repeat with V2 explicitly disabled and assert that the user's selection wins.
Until that test passes on the same configuration shipped to users, MultiAgentV2 should remain opt-in rather than being forced by model metadata.
Source confirmation
Confirmed against current source at 2b9c05046038c038ec6bddb9db7d11394995372d and the affected 0.144.x release family. The relevant behavior is directly encoded in:
codex-rs/models-manager/models.json(gpt-5.6-solselects V2)codex-rs/core/tests/suite/model_runtime_selectors.rs(catalog selector overrides feature flags)codex-rs/core/src/config/mod.rs(hide_spawn_agent_metadata = true)codex-rs/core/src/tools/handlers/multi_agents_spec.rs(routing fields are removed)codex-rs/core/src/tools/handlers/multi_agents_v2/spawn.rs(omittedfork_turnsbecomesall)codex-rs/core/src/tools/handlers/multi_agents_common.rs(full forks reject routing overrides and child runtime permissions are copied from the parent turn)
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗