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

Open 💬 4 comments Opened Jul 13, 2026 by spadaval
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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"
  1. Ask Sol to spawn that role. Using task_name = "research_analyst" creates only the path/name.
  2. Inspect the effective child configuration/rollout metadata. The affected behavior is agent_role = null, parent Sol model/effort, and the parent's permission profile.
  3. 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

  • #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_turns defaults 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:

  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)

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32031
  • #31814
  • #32674
  • #32587
  • #32703

Powered by Codex Action

gndk · 1 month ago

Good summary. Its really hard to understand how this could have even be released like this.

OAI team, please start actually using Codex internally instead of whatever custom harness you use currently. This would prevent a lot of the recent QA issues.

FRITS-Kh · 1 month ago

Confirmed in another currently affected environment:

  • IDE extension: 26.707.41301
  • codex-cli: 0.144.0-alpha.4
  • Platform: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64

The model-visible collaboration.spawn_agent schema exposes only:

  • task_name
  • message
  • fork_turns

There is no agent_type, subagent_type, model, reasoning_effort, or equivalent
role selector.

The project contains valid named custom agents under .codex/agents/*.toml, but
task_name only creates an instance label/path and does not select the configured
agent role. This makes the configured planner/reviewer/coder orchestration
workflow unusable.

Older multi_agent_v1 sessions on the same machine exposed agent_type, so this
also appears to be a regression or runtime/tool-surface mismatch in
MultiAgentV2/collaboration.spawn_agent.

michael0903 · 23 days ago

I can reproduce a stricter native catalog failure on the current published CLI (0.146.0) with ChatGPT authentication.

Reproduction:

  • Start a clean local CLI run with user config and rules ignored; explicitly enable features.multi_agent, features.multi_agent_v2, and agents.enabled.
  • Use gpt-5.6-terra as the parent and request exactly one native spawn_agent child with model: "gpt-5.6-luna" and fork_turns: "none"; the child has no tools.
  • The router rejects the request before child creation:

``text
Unknown model
gpt-5.6-luna for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra
``

Control: a top-level read-only codex exec -m gpt-5.6-luna succeeds under the same client, authentication, and policy.

This is upstream of the schema-visibility and default-full-fork problems: even an explicit fresh spawn reaches the router but receives a child-model catalog that excludes Luna. There is no local AGENTS.md, feature-flag, or general Luna-access explanation for this result.