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:
-
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.
-
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?
-
Configure a working non-OpenAI custom provider in ~/.codex/config.toml, for example:
[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"
-
Verify that direct execution works:
codex exec -p local_main --skip-git-repo-check --json "Reply with exactly: LOCAL_OK"
- 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.
"""
- 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."
- 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."
- 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:
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:
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:
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.
When the parent session itself uses the non-OpenAI custom provider, native subagent orchestration does not happen at all. No
spawn_agentcall 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?
Configure a working non-OpenAI custom provider in
~/.codex/config.toml, for example:Verify that direct execution works:
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_agentshould appear in the rolloutThis 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:
model_provider = openaiturn_context.model = gpt-5.4collaboration_mode.settings.model = gpt-5.4effort = highIn the custom-provider parent case:
company_local / code-fastspawn_agentcall appears in the rolloutThis 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: