MultiAgentV2 is fundamentally broken as a forced runtime and should not be imposed by model metadata #32705

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

1. The model catalog overrides the user's runtime selection. A model with multi_agent_version = "v2" selects V2 even when Feature::MultiAgentV2 is explicitly disabled. This behavior is deliberately covered by remote_multi_agent_selector_overrides_feature_flags.
2. V2 hides the routing controls by default. hide_spawn_agent_metadata = true removes agent_type, model, reasoning_effort, and service_tier from the model-visible spawn_agent schema. Despite its name, this setting removes functional inputs, not merely metadata from output.
3. Omitted fork_turns defaults to all. Therefore the natural/default spawn is a full-history fork.
4. Full-history forks reject heterogeneous routing. V2 rejects agent_type, model, and reasoning_effort overrides for a full-history fork and requires them to inherit from the parent.
5. task_name is 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 record agent_role = null and inherit Sol.
6. 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.
7. The apparent config workaround may collide with the server-reserved schema. Exposing the hidden fields under the default collaboration.spawn_agent namespace 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

1. Use Codex CLI 0.144.x with ChatGPT authentication and a clean/default configuration.
2. Start a fresh task using gpt-5.6-sol.
3. Observe that the model-selected runtime is V2 even if the local V2 feature is disabled.
4. Inspect the visible spawn_agent schema. On affected configurations it exposes only task_name, message, and fork_turns, not agent_type, model, reasoning_effort, or service_tier.
5. 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"

6. Ask Sol to spawn that role. Using task_name = "research_analyst" creates only the path/name.
7. Inspect the effective child configuration/rollout metadata. The affected behavior is agent_role = null, parent Sol model/effort, and the parent's permission profile.
8. If the hidden arguments are exposed or supplied, omit fork_turns and 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

• [CLI] GPT-5.5 forces MultiAgentV2 despite disable and hides documented custom-agent controls #31097 — model metadata forces V2 despite local configuration
• GPT-5.6 Sol cannot specify subagent models, forcing all subagents to also be Sol instances #31814 — Sol/V2 hides the model and role routing controls
• [Critical UX regression] multi-agent v2 spawn_agent hides model overrides and rejects the default call shape #32031 — hidden controls plus the default full-history call shape
• MultiAgentV2 spawn_agent defaults to full-history fork, rejecting agent_type/model overrides #20077 — fork_turns defaults to full history and rejects overrides
• 🩹 All GPT-5.6 Sol turns fail because MultiAgentV2 uses reserved collaboration.spawn_agent #31864 and MultiAgentV2: reserved spawn_agent schema blocks per-child model and reasoning-effort overrides #32674 — reserved namespace/schema incompatibility
• Tool-backed subagents silently inherit Sol Ultra instead of custom agent model settings #32587 and spawn_agent cannot bind to custom [agents.*] profiles in Codex App config.toml #32703 — named roles silently become generic inherited children
• MultiAgentV2 canonical activity items omit effective subagent identity/model/effort metadata #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:

1. Treat the catalog's multi_agent_version as a default, not an override of an explicit user selection.
2. Remove the forced V2 selector from Sol/Terra until the complete clean-install workflow passes end to end.
3. Expose agent_type, model, reasoning_effort, and service_tier in a backend-compatible schema.
4. Default fork_turns to none, or make explicit role/model overrides compatible with omitted/full-history forking.
5. Keep task_name and role selection distinct and expose a real role selector.
6. 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.
7. 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:

1. Select Sol.
2. Register a Terra/medium/read-only role and a Luna/low/read-only role.
3. Spawn both through the exact model-visible tool schema.
4. Assert their effective model, effort, role, permission profile, task delivery, and completed metadata.
5. 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-sol selects 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 (omitted fork_turns becomes all)
• 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)