Native subagent orchestration does not work correctly with non-OpenAI custom providers

What version of Codex CLI is running?

0.120.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 5.19.0-43-generic x86_64 x86_64, Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64

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

Windows Terminal using WSL and PowerShell

What issue are you seeing?

In codex-cli 0.120.0, native subagents do not work correctly with a non-OpenAI custom provider.

I observed two related failures:

1. When the parent session uses OpenAI and the child subagent is configured with a non-OpenAI custom provider, the child rollout is created, but the child keeps the parent OpenAI config instead of applying the custom provider config.

1. When the parent session itself uses the non-OpenAI custom provider, native subagent orchestration does not happen at all. No spawn_agent call appears in the rollout, no child rollout is created, and the parent answers directly.

OpenAI-only native subagents work correctly in the same environment, so this appears to be specific to native subagents with non-OpenAI custom providers.

What steps can reproduce the bug?

1. Configure a working non-OpenAI custom provider in ~/.codex/config.toml, for example:

```toml
[model_providers.company_local]
name = "Company Local LLM"
env_key = "LOCAL_LLM_API_KEY"
wire_api = "responses"

[profiles.local_main]
model_provider = "company_local"
model = "code-fast"

[profiles.local_fast]
model_provider = "company_local"
model = "code-fast"

1. Verify that direct execution works:

``
codex exec -p local_main --skip-git-repo-check --json "Reply with exactly: LOCAL_OK"
``

1. Add a custom subagent config like:

name = "local_llm_worker"
model_provider = "company_local"
model = "code-fast"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
Use the local LLM provider for read-only code exploration.
"""

1. Reproduce failure case 1, OpenAI parent to custom-provider child:

codex --enable multi_agent_v2 exec -p openai_heavy --skip-git-repo-check --json "Use the local_llm_worker subagent for read-only exploration only. If the subagent runs, end with exactly LOCAL_WORKER_OK. If unavailable, end with exactly LOCAL_WORKER_UNAVAILABLE."

1. Reproduce failure case 2, custom-provider parent session:

codex --enable multi_agent_v2 exec -p local_main --skip-git-repo-check --json "You must use the local_llm_worker subagent via native subagent spawning, not by answering yourself. Read-only exploration only. End with exactly LOCAL_PARENT_LOCAL_CHILD_OK or LOCAL_PARENT_LOCAL_CHILD_UNAVAILABLE."

1. Optionally repeat the same test with another custom-provider parent profile such as local_fast.

What is the expected behavior?

Native subagents should work consistently with non-OpenAI custom providers.

Expected behavior:

• If a child subagent specifies:
• model_provider = "company_local"
• model = "code-fast"
• model_reasoning_effort = "medium"

then the spawned child session should reflect those values in its effective config.

• If the parent session uses a non-OpenAI custom provider, native subagent orchestration should still occur normally:
• spawn_agent should appear in the rollout
• a child rollout should be created
• the parent should not answer directly instead of spawning the child

This should behave analogously to OpenAI-only native subagents, which work correctly in the same environment.

Additional information

What works:

• Direct execution with the custom provider works correctly
• OpenAI-only native subagents work correctly
• A custom subagent with:
• model_provider = "openai"
• model = "gpt-5.4-mini"

correctly produces a child rollout with the expected provider/model/effort values

Observed failure details:

• In the OpenAI parent -> custom-provider child case:
• child rollout is created
• agent identity and developer instructions are applied
• but child config remains on parent OpenAI values:
• model_provider = openai
• turn_context.model = gpt-5.4
• collaboration_mode.settings.model = gpt-5.4
• effort = high

• In the custom-provider parent case:
• parent starts correctly on company_local / code-fast
• no spawn_agent call appears in the rollout
• no child rollout file is created
• parent answers directly

This makes it look like native subagent support is incomplete or broken for non-OpenAI custom providers, both in child config merging and in orchestration from a custom-provider parent.

Related issues:

• #11701
• #13204
• #14039
• #15170
• #13849