What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.707.51957 (build 5175), embedded codex-cli 0.144.0-alpha.4

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

In the Codex App, a parent session running gpt-5.6-sol / ultra silently spawns every tool-backed multi-agent v2 child I inspected with the same model and effort, even when the intended custom agent is configured for a different model.

For example, I have a valid personal custom agent at ~/.codex/agents/explorer.toml with:

name = "explorer"
description = "Read-only explorer for bounded code investigations."
model = "gpt-5.6-luna"
model_reasoning_effort = "high"
sandbox_mode = "read-only"
developer_instructions = """
Perform bounded read-only exploration and return evidence.
"""

The exposed spawn_agent tool in this session only accepts task_name, message, and fork_turns. It does not expose agent_type, model, or reasoning_effort.

Even when I use the exact custom agent name as task_name: "explorer" with fork_turns: "none", the child rollout records:

• session_meta.payload.source.subagent.thread_spawn.agent_role: null
• turn_context.payload.model: "gpt-5.6-sol"
• turn_context.payload.effort: "ultra"

Creating a custom default agent pinned to Luna High did not change the result. Trying to apply a model override to the already-created child was rejected with:

direct app-server input is not allowed for multi-agent v2 sub-agents

This looks like a runtime/tool-schema mismatch rather than an unavailable-model problem: a separate codex exec control run with -m gpt-5.6-luna and model_reasoning_effort="high" correctly recorded Luna High.

The silent fallback is especially problematic because it causes unexpectedly high Sol Ultra usage while the parent believes it delegated work to cheaper role-specific workers.

What steps can reproduce the bug?

1. Start a Codex App task with the main model set to gpt-5.6-sol / ultra.
2. Add a valid custom agent under ~/.codex/agents/explorer.toml with model = "gpt-5.6-luna" and model_reasoning_effort = "high".
3. Ask the main task to start that exact custom agent. The tool call available in my session is:

{
  "task_name": "explorer",
  "fork_turns": "none",
  "message": "Model-routing probe. Do not use tools; reply with one fixed marker."
}

4. Wait for the child to finish.
5. Inspect the child's saved rollout session_meta and turn_context.
6. Observe that agent_role is null and the child is gpt-5.6-sol / ultra, not gpt-5.6-luna / high.
7. Repeat with a custom default agent pinned to Luna High. The child still inherits Sol Ultra.
8. As a control, run codex exec -m gpt-5.6-luna -c 'model_reasoning_effort="high"'; the resulting rollout correctly reports Luna High.

Session IDs:

• Parent: 019f4b1b-04e4-7290-b2e8-89b6ddac2827
• Exact-name explorer child: 019f5691-6847-7131-804c-a25831f21b12
• Custom-default probe child: 019f5693-6585-75c3-af75-9fcbba7f3072
• Explicit Luna High CLI control: 019f5696-2dbb-7632-b3a6-6069f62f19fa

What is the expected behavior?

A tool-backed subagent launch should do one of the following:

1. Expose agent_type, model, and reasoning_effort so the caller can select the registered custom agent or explicit model settings.
2. Resolve an exact registered custom-agent name and apply that agent's model, model_reasoning_effort, instructions, and sandbox.
3. If the surface cannot support role/model overrides, fail explicitly before starting the child instead of silently inheriting the expensive parent model.

The child activity UI and saved rollout should also make the actual model and reasoning effort clear.

Additional information

Impact: all workers intended to run as Luna High, Luna xhigh, Sol Medium, or Sol High can silently become Sol Ultra. This increases usage substantially and makes role-based orchestration unreliable.

Current workaround: avoid the in-app spawn_agent path, launch an independent codex exec worker with explicit model/effort/sandbox and agents.max_depth=0, then verify the saved rollout's turn_context. This loses first-class in-app subagent orchestration and is not an adequate long-term replacement.