gpt-5.6-sol/terra/luna: multi_agent_version=v1 override (per #31882 workaround) still doesn't expose spawn_agent against a custom model_provider on 0.146.0

[l3aki]

What version of Codex CLI is running?

codex-cli 0.146.0 (codex --version)

What subscription do you have?

Not applicable to the reported bug — this is a custom model_providers entry pointing at a local self-hosted reverse proxy (a personal Rust project translating the Responses API to a Kiro/Bedrock-backed model), not Azure or ChatGPT. wire_api = "responses", env_key auth (no ChatGPT sign-in for this profile).

Which model were you using?

gpt-5.6-terra

What platform is your computer?

Darwin 25.5.0 arm64 arm (macOS, Apple Silicon)

What terminal emulator and version are you using (if applicable)?

Orca app-managed terminal environment (CODEX_HOME pointed at an Orca-managed per-account directory), also reproduced directly via codex exec in a plain shell with the same profile/config — behavior is identical in both.

Codex doctor report

not available (redacted local paths in this environment; happy to provide a sanitized one on request)

What issue are you seeing?

Following the workaround documented in #31882 / #31875 / #31864 / #31870 (force multi_agent_version: "v1" for gpt-5.6-sol/terra/luna via a local model_catalog_json override, plus [features] multi_agent = true, multi_agent_v2 = false), spawn_agent still does not become available against a custom (non-ChatGPT, non-Azure) model_providers entry on 0.146.0. The reported symptom differs from the original wire-format 400s those issues describe:

• Without any override: the model calls spawn_agent, and it fails at dispatch with error=unsupported call: spawn_agent from codex_core::tools::router (a purely local error — no network round-trip visible in the log before it — i.e. the tool call reaches the client but the router has no handler for it).
• With the model_catalog_json + [features] override applied (verified working via codex debug models, and verified the static catalog is actually engaged for codex exec — no models_manager: failed to refresh available models fallback attempt occurs once the override is in place, confirming StaticModelsManager is active): the tool disappears from the model's visible toolset entirely instead — the model replies "I don't have a spawn_agent tool available in this session," meaning spawn_agent/list_agents/etc. never get registered at all under the override, rather than registering and failing.

I dug into the public source to understand why (codex-rs/core/src/tools/spec_plan.rs, codex-rs/core/src/session/mod.rs, codex-rs/core/src/config/mod.rs, codex-rs/models-manager/src/manager.rs). As far as I can trace from the outside:

• add_collaboration_tools only registers anything when collab_tools_enabled(turn_context) is true, which for MultiAgentVersion::V1 should just be a depth-limit check (!exceeds_thread_spawn_depth_limit(...)) — not provider-gated at that layer.
• Config::multi_agent_version_for_model resolves as multi_agent_version_override().or(model_multi_agent_version).unwrap_or_else(multi_agent_version_from_features), and multi_agent_version_override() only returns Some when Feature::MultiAgentV2 is enabled or agents_enabled is false — neither applies here, so on paper this should fall through to the catalog's overridden Some(V1).

Despite that, the tool never gets registered, which suggests either an additional provider/auth-based gate somewhere in ModelInfo construction (e.g. inside construct_model_info_from_candidates / with_config_overrides, or in ProviderCapabilities resolution) that isn't visible from the public repo search I could do, or a behavior change between 0.144 (when the model_catalog_json workaround was verified working against Azure in #31882) and 0.146 that re-tightened this. I wasn't able to attach a debugger to the compiled binary to confirm further.

Filing this as a distinct report (rather than a comment on #31882) since the symptom and root cause appear to differ: #31882 is about the provider rejecting a malformed request (fixable by not sending Lite/collaboration-namespace transport to providers that don't support it); this is about the client-side tool registry never exposing spawn_agent at all even once that mitigation is applied, against a provider that isn't Azure or the ChatGPT-hosted backend.

What steps can reproduce the bug?

# $CODEX_HOME/config.toml
[model_providers.my-custom-provider]
name = "My Custom Provider"
base_url = "http://localhost:PORT/v1"
env_key = "MY_CUSTOM_API_KEY"
wire_api = "responses"

# $CODEX_HOME/my-profile.config.toml
model_provider = "my-custom-provider"
model = "gpt-5.6-terra"
model_catalog_json = "$CODEX_HOME/patched-models.json"

[features]
multi_agent = true
multi_agent_v2 = false

patched-models.json = full bundled catalog (codex debug models output, or the cached models_cache.json) with gpt-5.6-sol/gpt-5.6-terra/gpt-5.6-luna entries patched to "multi_agent_version": "v1", "use_responses_lite": false, "tool_mode": null, all other fields left untouched.

MY_CUSTOM_API_KEY=dummy codex --profile my-profile exec --skip-git-repo-check \
  "Use spawn_agent to spawn a sub-agent named 'ping_test' with the message 'reply with exactly: PONG'. Then wait for it to finish and report its final answer verbatim."

Confirm the override is actually engaged first with:

codex -c model_catalog_json="$CODEX_HOME/patched-models.json" debug models
# should show "multi_agent_version": "v1" for the three models

What is the expected behavior?

Either:

• spawn_agent/list_agents/etc. become available and function (using the older, provider-agnostic V1 collaboration implementation) once multi_agent_version is successfully forced to v1 for these models via model_catalog_json + [features] multi_agent_v2 = false, matching what gpt-5.6-sol/terra/luna hardcode use_responses_lite / multi_agent_version, causing 400s on Azure (and likely any non-ChatGPT-backend) model_provider #31882's thread describes working for Azure on 0.144.0; or
• If V1 collaboration tools are intentionally restricted to the ChatGPT/Codex-hosted backend regardless of multi_agent_version, that restriction should be documented (and ideally surfaced as a clear error/warning at startup, e.g. "collaboration tools require the Codex-hosted backend") rather than the tool silently disappearing from the model's toolset with no diagnostic, or the model receiving a bare unsupported call: spawn_agent router error with no explanation of why.

Additional information

• gpt-5.5 / gpt-5.4 (which don't carry multi_agent_version/use_responses_lite in the bundled catalog) work fully, including with [features] multi_agent = true alone (no multi_agent_v2 override needed) — collaboration tools register and I haven't tested spawn execution end-to-end on those, but they are at least visible/callable, unlike gpt-5.6-terra under any configuration I tried.
• Everything else about gpt-5.6-terra against this custom provider works correctly, including Codex's own exec/unified_exec shell tool and MCP tool use — this is specific to the collaboration/multi-agent namespace.
• Related: gpt-5.6-sol/terra/luna hardcode use_responses_lite / multi_agent_version, causing 400s on Azure (and likely any non-ChatGPT-backend) model_provider #31882, Codex CLI with Azure OpenAI gpt-5.6-sol fails due to Codex-specific tools / collaboration namespace #31875, 🩹 All GPT-5.6 Sol turns fail because MultiAgentV2 uses reserved collaboration.spawn_agent #31864, Codex with GPT-5.6-Sol through Azure fails every turn with X-OpenAI-Internal-Codex-Responses-Lite #31870, Multi-Agent V2 sends OpenAI-specific agent_message items to external Responses providers #33551 ("Multi-Agent V2 sends OpenAI-specific agent_message items to external Responses providers" — plausibly the deeper reason V1-forcing doesn't help if V1 itself turns out to also be gated, or if something downstream still assumes V2/Lite semantics).