gpt-5.6-luna is marked as MultiAgent V1, so V2 spawn_agent rejects it

[Arbiter5ItsSoul]

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

pro20x

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

No response

Codex doctor report

What issue are you seeing?

gpt-5.6-luna is marked as MultiAgent V1 in the model catalog. In a MultiAgent V2 session, spawn_agent only allows models marked for V2, so Luna
cannot be selected:

Unknown model gpt-5.6-luna for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra.

What steps can reproduce the bug?

1. Start a session using MultiAgent V2.
2. Call spawn_agent with model="gpt-5.6-luna" and fork_turns="none".
3. Observe that the request is rejected because Luna is not available as a V2 model.

What is the expected behavior?

gpt-5.6-luna should be marked as supporting MultiAgent V2 and should be accepted as a spawn_agent model override.

Additional information

No response

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• spawn_agent does not expose gpt-5.6-luna #34964
• Codex App 26.715.9868.0 / CLI 0.145.0: spawn_agent rejects gpt-5.6-luna with multi_agent_v2 enabled #34700
• GPT Sol and Terra threads cannot spawn Luna subagents because of Luna Multi Agent version #34301
• Regression: luna cannot be specified in spawn_agent tool model anymore, e.g. for Explorer #34024
• Codex CLI 0.145.0: spawn_agent rejects gpt-5.6-luna even though /model lists it #34909

Powered by Codex Action

[CHKKOREA]

Additional reproduction on macOS with a newer build:

• Date: 2026-07-24 KST
• Codex Desktop build: 26.721.31836
• Codex CLI: 0.146.0-alpha.3.1
• Parent: gpt-5.6-sol / medium
• Requested child: gpt-5.6-luna / high
• Call shape: spawn_agent(model="gpt-5.6-luna", reasoning_effort="high", fork_turns="none")

Actual result remains:

Unknown model `gpt-5.6-luna` for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra

No child session is created. This reproduced in a fresh top-level Codex Desktop task. The local raw model catalog exposes Luna, while the current native spawn_agent allowlist still exposes only Sol and Terra, consistent with the V1/V2 mismatch described in this issue.

Diagnostics were uploaded via /feedback under thread ID: 019f9305-00c7-7c22-a4e6-6485cdff2953.

[MattBetancourt]

Additional reproduction on Linux with the current stable release:

• Codex CLI: 0.145.0 (npm latest)
• Parent session: gpt-5.6-terra, medium reasoning
• Multi-agent V2 active; native spawn_agent override controls exposed
• No local subagent-model allowlist or Luna-disabling configuration

Luna is rejected before a child is created in each tested shape:

model="gpt-5.6-luna", reasoning_effort="low",  fork_turns="none"
model="gpt-5.6-luna", reasoning_effort="high", fork_turns="none"
model="gpt-5.6-luna", reasoning_effort="low",  fork_turns="3"

All return:

Unknown model `gpt-5.6-luna` for spawn_agent.
Available models: gpt-5.6-sol, gpt-5.6-terra

Control spawns using explicit gpt-5.6-sol and gpt-5.6-terra with fork_turns="none" and low reasoning succeeded.

This confirms the failure is not caused by local configuration, fork mode, or reasoning effort; it appears to be the model-catalog / MultiAgent V1–V2 routing mismatch described in this issue.

Feedback uploaded from thread: 019fa563-3d4d-77f0-b87c-93cf38da74dd.

[TiraelSedai]

i have the same issue

[gguryuryu]

Reproduced this on macOS with Codex app 26.721.41059 and CLI 0.146.0-alpha.3.1.

Parent model: gpt-5.6-sol

Child request: model=gpt-5.6-luna, reasoning_effort=medium, fork_turns=none

The result is the same:

Unknown model `gpt-5.6-luna` for spawn_agent. Available models: gpt-5.6-sol, gpt-5.6-terra

As a control, an explicit Terra medium spawn from the same parent completed successfully. I also checked the current main catalog: Sol and Terra are marked multi_agent_version: v2, while Luna is still marked v1. That lines up with the V2 backend filter described here.

I am not sure whether changing the bundled model metadata is sufficient, or whether the server-side catalog/backend needs a corresponding update as well. If Luna is intended to support V2 and a maintainer is open to an external contribution, I would be happy to send a focused PR with regression coverage. Otherwise I can provide additional session metadata if useful.

[himomohi]

I reproduced this on macOS with stable codex-cli 0.146.0 and verified that the catalog metadata gate is the blocker in this environment.

Runtime proof

1. Preserved the authenticated model cache unchanged.
2. Loaded a separate model_catalog_json whose only semantic change was gpt-5.6-luna.multi_agent_version: "v1" -> "v2".
3. Started a fresh native multi-agent v2 CLI process.
4. Spawned exactly one child with model="gpt-5.6-luna", reasoning_effort="high", and fork_turns="none".
5. The child was created as /root/luna_v2_smoke and returned the exact marker LUNA_V2_OK. No model fallback was reported.

This shows that, for the tested CLI/backend combination, Luna can complete a v2 child run once it passes the catalog compatibility filter. The current v1 metadata appears to be the immediate blocker rather than a backend execution failure. This is still bounded evidence from one environment, not a claim about every Codex surface.

I prepared the smallest upstream candidate: change only the bundled Luna metadata in codex-rs/models-manager/models.json from v1 to v2.

• Branch: https://github.com/himomohi/codex/tree/agent/enable-luna-multi-agent-v2
• Commit: himomohi@e0dc7fb
• Compare: main...himomohi:codex:agent/enable-luna-multi-agent-v2
• Validation: just fmt; just test -p codex-models-manager — 41/41 passed

I have not opened an unsolicited PR because docs/contributing.md says external PRs require a maintainer invitation. If this metadata change matches the intended backend rollout, I would be happy to open the focused PR when invited.

[kendonB]

Still not working on WSL