What version of Codex CLI is running?

codex-cli 0.106.0

What subscription do you have?

N/A (using custom provider via model_providers + env key)

Which model were you using?

N/A

What platform is your computer?

Darwin 24.6.0 arm64 arm

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

Ghostty (xterm-ghostty), shell: /bin/zsh

What issue are you seeing?

When running with --profile p-name, parent session uses the correct custom provider, but role-based subagents (for example agent_type=explorer / agent_type=awaiter) fall back to openai and call https://api.openai.com/v1/responses.

This causes auth failures like:

unexpected status 401 Unauthorized: Missing bearer or basic authentication in header, url: https://api.openai.com/v1/responses

Important distinction:

• spawn_agent with default role (no agent_type) keeps provider correctly.
• spawn_agent with role config (explorer / awaiter) falls back to openai.

Observed thread data from repro:

• Parent rollout session_meta.model_provider: p-name
• Child rollout session_meta.model_provider: openai

What steps can reproduce the bug?

1. Configure a custom provider + profile in ~/.codex/config.toml, e.g.:

[model_providers.my-provider]
base_url = "https://example.com/v1"
env_key = "MY_PROVIDER_API_KEY"
wire_api = "responses"

[profiles.my-profile]
model = "..."
model_provider = "my-provider"
sandbox_mode = "danger-full-access"
approval_policy = "on-failure"

2. Run:

MY_PROVIDER_API_KEY=... \
codex exec --skip-git-repo-check --profile my-profile --json \
"Spawn one subagent with agent_type explorer. Ask it to reply exactly SUBAGENT_OK. Then wait."

3. Observe repeated reconnect + 401 errors against https://api.openai.com/v1/responses.

4. Compare rollout metadata for parent and child:

• parent shows model_provider: my-provider
• child shows model_provider: openai

What is the expected behavior?

Subagents should inherit the parent turn’s active profile/provider context (or at least the resolved provider) even when agent_type role config
is applied.

Additional information

No response