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

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

• #34964
• #34700
• #34301
• #34024
• #34909

Powered by Codex Action

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.

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.

i have the same issue

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.

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: https://github.com/himomohi/codex/commit/e0dc7fb
• Compare: https://github.com/openai/codex/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.

Still not working on WSL

Please prioritize this fix. The current V1/V2 mismatch blocks one of the most useful multi-agent configurations: using Sol as the orchestrator while delegating bounded investigation and routine work to Luna children.

The available workarounds—using Luna as the parent or launching separate codex exec processes—lose the intended native orchestration workflow and are unnecessarily cumbersome. It also forces users toward more expensive child models when Sol/Terra are the only selectable V2 options.

At minimum, please clarify whether Luna V2 support is planned and whether this requires a server-side rollout in addition to the model-catalog change. A status update or target release would be useful.

Additional regression detail from my recent Codex Desktop usage:

• In late-July sessions, Luna was sometimes omitted from the advertised spawn_agent model list, but explicitly passing the known fields—such as model="gpt-5.6-luna", a reasoning effort, and fork_turns="none"—could still create a Luna child.
• After the recent runtime updates, the same explicit call is rejected before any child is created:

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

• An explicit Terra child succeeds in the same session. Omitting the model does not honor the configured Luna worker either; it inherits/falls back to the Sol parent.

So this has worsened from a discoverability/schema problem into hard capability enforcement. Prompting the controller to use the hidden-but-valid Luna override used to be a workable path; it is no longer possible.

This blocks one of the most valuable native multi-agent configurations: Sol as controller, Luna as the bounded execution worker for repository search, targeted context reading, spec implementation, tests, and routine code changes. Replacing every Luna worker with Sol or Terra raises usage and cost, while launching a separate codex exec process loses the native child thread, orchestration, context handoff, and Subagents-panel workflow.

This is especially counterproductive after the announced Luna price reduction: https://x.com/OpenAI/status/2082878156483219672. A major practical value of that price change is precisely to make high-reasoning Luna workers economical at scale under a stronger controller. Keeping Luna excluded from native Multi-Agent V2 undermines that benefit.

Please prioritize this regression. At minimum, it would help to clarify:

1. whether Luna V2 child support is planned;
2. whether the fix requires only the model-catalog metadata change or also a server-side rollout;
3. which release is expected to restore Sol/Terra -> Luna native spawning.

There is already bounded runtime evidence in this thread that changing Luna's catalog metadata from v1 to v2 allows a native Luna child to run successfully in at least one environment.

Independent fix and regression coverage for the same catalog gate, extending @himomohi's runtime report with a Max child and a Core behavioral test.

Environment:

• macOS
• Codex Desktop bundled CLI 0.146.0-alpha.9.2
• upstream main base: 6751b54cae32b23786001e2414d749a9916201e1

Before the fix, a fresh Multi-Agent V2 run rejected Luna before creating a child:

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

The candidate changes only two lines:

• Change bundled gpt-5.6-luna.multi_agent_version from v1 to v2.
• Update the existing Core behavioral regression so the V2 eligible-model list must include Luna.

TDD evidence:

1. With only the regression expectation changed, the test failed because the actual list still contained only Sol and Terra.
2. After the Luna catalog change, the same test passed.

Validation:

• Exact Core regression: 1/1 passed
• just test -p codex-models-manager: 42/42 passed
• just test -p codex-core multi_agent_v2: 76/76 passed
• just fmt: passed

Runtime proof after applying the same one-field catalog override locally:

• Parent: gpt-5.6-sol, low
• Configured default child: gpt-5.6-luna, max
• Fork mode: none
• Persisted child context records model=gpt-5.6-luna and effort=max
• Child path /root/luna_v2_smoke returned LUNA_V2_OK

Contribution:

• Branch: https://github.com/zhangsugang/codex/tree/fix/luna-v2-subagents
• Commit: https://github.com/zhangsugang/codex/commit/b0688b2ad66290cd158648bcc7e915d70f7427a3
• Compare: https://github.com/openai/codex/compare/main...zhangsugang:codex:fix/luna-v2-subagents

Per the repository contribution policy, I have not opened an unsolicited PR. If this matches the intended Luna backend rollout, please invite the focused PR and I will submit it immediately.

Temporary workaround verified with codex-cli 0.146.0:

1. Create a patched model catalog:

``sh
mkdir -p "$HOME/.codex/model-catalogs"
codex debug models \
| jq '(.models[] | select(.slug == "gpt-5.6-luna") | .multi_agent_version) = "v2"' \
> "$HOME/.codex/model-catalogs/luna-v2.json"
``

select(...) limits the change to Luna, while the output remains a complete catalog suitable for model_catalog_json.

1. Add this to ~/.codex/config.toml, using your absolute home path:

``toml
# Temporary workaround for https://github.com/openai/codex/issues/35097
model_catalog_json = "/Users/<username>/.codex/model-catalogs/luna-v2.json"
``

1. Restart Codex

Persisted child runtime metadata—not the child's natural-language response—confirmed model=gpt-5.6-luna, effort=high, and multi_agent_version=v2. The child completed 43 tool calls across two turns.

This pins the complete model catalog. Remove the config line and catalog file once the issue is fixed.

<img width="1028" height="687" alt="Image" src="https://github.com/user-attachments/assets/906262b5-2117-4a8b-a5e3-1a8c94029081" />
Same issue, agent cant access luna and other models.

[features.multi_agent_v2]
hide_spawn_agent_metadata = false
tool_namespace = "agents"

setting these values in the ~/.codex/config.toml worked

[features.multi_agent_v2]

hide_spawn_agent_metadata = false
tool_namespace = "agents"

This didn't work for me, issue still persists even after restarting codex.

I've tried the same prompt from @KarmicDaoist but couldn't replicate a similar response.

I'm unsure if environment or something else affects it, but i didn't try any of the workarounds (i'm on Windows btw).

v26.727.51351

<img width="847" height="710" alt="Image" src="https://github.com/user-attachments/assets/d4b0dcb6-3c2a-4139-8c32-aa9d5fa94bc2" />

Edit: Despite the above, when forcing the use of luna max subagents, i still get limitations that show that it isn't available

Available models: gpt-5.6-sol, gpt-5.6-terra

@Ronkiro try this prompt to fix this error

2 prompts you can give Codex to make Codex work better:

Let Codex ask questions outside Plan mode

Paste this prompt:
Update my personal Codex config. Under the existing [features] section, add default_mode_request_user_input = true. Create the section if it doesn’t exist, preserve every existing setting, avoid duplicate keys, and validate the final TOML. If I use both Windows and WSL, update both config files. Tell me whether Codex needs to be restarted.

This lets Codex check in when it needs an important decision instead of silently proceeding with the wrong assumption.

Let Sol call Luna as a subagent
Paste this prompt:
Inspect my active Codex model catalog and determine whether Multi-Agent V2 is filtering gpt-5.6-luna because Luna is marked with "multi_agent_version": "v1". If confirmed, do not modify the stock models_cache.json. Copy it to a custom catalog, change only Luna’s marker to "multi_agent_version": "v2", and point model_catalog_json in my active config.toml to the custom file using its absolute path. Leave hidden or special-purpose models unchanged. Validate the JSON and TOML, confirm Luna is exposed as a subagent model, and tell me to restart Codex.

Then add this routing guidance to AGENTS.md:

Use Sol for planning, orchestration, and reviews.

Use Luna for implementation and routine investigation. When spawning Luna, use model="gpt-5.6-luna" and fork_turns="none".
The result: Sol handles judgment, Luna handles execution, and Codex asks instead of guessing.

The Luna catalog change is a workaround and may need to be refreshed after a Codex update.

https://github.com/openai/codex/commit/6d4d9442c7142c08ac5c5098dfd6e82d8cd9f65a

Reproduced again on macOS 26.6 with ChatGPT/Codex Desktop 26.730.61639 and its bundled Codex CLI 0.147.0-alpha.1.2.

• Parent: gpt-5.6-sol / xhigh
• Requested named child role resolves to: gpt-5.6-luna / xhigh
• Fork mode: none

Native spawn_agent still returns:

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

The bundled model catalog currently reports:

gpt-5.6-sol   multi_agent_version=v2
gpt-5.6-terra multi_agent_version=v2
gpt-5.6-luna  multi_agent_version=v1

A separate top-level Luna CLI worker is available in the same environment, so this is specific to native child spawning rather than account-level Luna availability.

I see that #36892 / commit 6d4d9442 ("Support leaf models in multi-agent v2") merged on 2026-08-04. This Desktop bundle apparently does not include that behavior yet; the note may be useful for confirming which release first ships the fix.

Additional reproduction from Codex Desktop on macOS:

• Codex Desktop: 26.730.61639 (build 6234)
• Codex CLI: 0.144.6
• macOS 26.2, arm64
• Restarted the app before retesting

The host model catalog and task-creation surface expose gpt-5.6-luna as available. However, an explicit collaboration call:

{
  "task_name": "luna_status_audit",
  "fork_turns": "all",
  "model": "gpt-5.6-luna",
  "reasoning_effort": "high"
}

is rejected with:

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

This persists after restarting Codex. The discrepancy is especially confusing because the same host explicitly advertises Luna for creating a top-level Codex task, while the collaboration spawn_agent schema/runtime excludes it. No local [agents] model allowlist configuration appears to exist; [agents] only has settings such as max_depth.

Additional controlled reproduction on Codex Desktop for Windows, after the merge of #36892:

• Codex Desktop: 26.803.5235.0
• Bundled runtime: 0.147.0-alpha.6.5
• Same Windows host, project and configuration
• Two fresh tasks created together

Results:

• Sol high received multi_agent_version=v2. Its spawn_agent interface exposed only Sol and Terra, and rejected Luna xhigh.
• Luna xhigh received multi_agent_version=v1 and successfully spawned a Luna xhigh child, which returned LUNA_SPAWN_OK.

Exact Sol error:

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

This confirms that Luna is available for the account and as a top-level model. The failure is specific to spawning it as a child from a Sol/V2 task.

Since #36892 (“Support leaf models in multi-agent v2”) is included in the Codex CLI 0.147.0 changelog, it appears that this Windows Desktop bundle does not yet expose the corrected leaf-model behavior.

Could a maintainer confirm which Windows Desktop build includes #36892? I can submit feedback from the affected task and provide the task IDs or local session metadata if useful.

Additional sanitized A/B reproduction on macOS:

Environment

• Codex Desktop: 26.803.41515 (build 6321)
• Bundled runtime: 0.147.0-alpha.6.5
• Standalone stable CLI: 0.147.0
• Latest npm alpha tested separately: 0.147.0-alpha.6.6
• Parent: gpt-5.6-sol / high, with multi_agent_version=v2
• Configured default child: gpt-5.6-luna / max

Minimal call

spawn_agent(
  agent_type="explorer",
  fork_turns="none",
  model omitted
)

The omitted model resolves through the configured default subagent model to gpt-5.6-luna / max.

Results

Standalone stable 0.147.0: succeeds.

The persisted child metadata confirms:

model=gpt-5.6-luna
reasoning_effort=max
multi_agent_version=v2

This was a real Luna child, not a fallback to Sol or Terra.

Alpha 0.147.0-alpha.6.6: fails before creating a child.

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

The parent metadata still reports multi_agent_version=v2.

Desktop bundled 0.147.0-alpha.6.5: fails with the same error.

This controlled comparison used the same machine, model configuration, and call shape. It suggests the leaf-model support present in stable 0.147.0 is missing or not active in the alpha.6.x runtime path.

No project files, source code, task identifiers, local paths, or account-specific details are included.

Damn, big company can't set 2 instead 1 on server for a whole month :(

This is intentional : https://x.com/pvncher/status/2083300990350954981?s=20

This is intentional : https://x.com/pvncher/status/2083300990350954981?s=20

Implement required communication? Nah, tell everyone we are not recommending it...

I mean, we should keep asking for a way to use Luna as subagents, but Luna being marked as V1 is fully intentional and shouldn't be filed as a bug.

It finally happened!

Soooo, this can be fixed then :)

For MultiAgent V2 sessions where spawn_agent rejects gpt-5.6-luna: the model catalog marks luna as MultiAgent V1, and V2 sessions only accept models catalogued as V2.

Method:

1. Quick path: use gpt-5.6-sol or gpt-5.6-terra for spawn_agent in V2 sessions — both are catalogued as V2, and the rejection message lists exactly the accepted models.
2. If you specifically need luna in a V2 session, the catalog is user-overridable: point the documented model_catalog_json config key (applied on startup) at a copy of the catalog with luna's multi_agent_version set to "v2", then restart codex.

Evidence: the model catalog on main (codex-rs/models-manager/models.json) shows gpt-5.6-luna with multi_agent_version=v1 while gpt-5.6-sol/gpt-5.6-terra are v2; the config schema documents model_catalog_json as an optional path to a JSON model catalog.

Independent community workaround; not an official OpenAI fix.

Confirmed this against a fresh clone of main today. In codex-rs/models-manager/models.json the model presets currently read:

gpt-5.6-sol   -> "multi_agent_version": "v2"
gpt-5.6-terra -> "multi_agent_version": "v2"
gpt-5.6-luna  -> "multi_agent_version": "v1"

This single mislabeled field is the root cause of the V2-rejection behavior described above (via model_supports_multi_agent_backend in codex-rs/core/src/tools/handlers/multi_agents_common.rs, introduced in #32751).

Additional symptom worth noting: it also affects the V1-only path. With features.multi_agent = true and features.multi_agent_v2 = false (codex-cli 0.149.1), running the active model as gpt-5.6-luna never exposes the multi_agent_v1__list_agents tool at all — no error, the tool simply doesn't appear in the toolset for that session. Same root mislabel, different failure mode (tool never registered instead of spawn_agent rejecting a child model).

Fix should just be flipping that one field to "v2" for gpt-5.6-luna, matching sol/terra.