spawn_agent does not expose gpt-5.6-luna

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

• #34909
• #34700
• #34399
• #34301
• #34024

Powered by Codex Action

Confirmed in another current environment:

• Platform: macOS (Darwin 25.5.0, arm64)
• Codex CLI: 0.145.0
• Parent model: gpt-5.6-sol
• Multi-agent tools: enabled

The model-visible spawn_agent override list exposes only gpt-5.6-sol and gpt-5.6-terra; gpt-5.6-luna is not selectable. This reproduces the reported mismatch even though Luna is available as a main-session model.

Reproduced on Windows with Codex CLI 0.146.0 and ChatGPT authentication.

Additional diagnostics:

• ~/.codex/config.toml sets:

default_subagent_model = "gpt-5.6-luna"

• codex debug models lists gpt-5.6-luna.
• codex exec -m gpt-5.6-luna succeeds.
• Explicit spawn_agent(model="gpt-5.6-luna") fails:

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

• Calling spawn_agent without a model also fails because it resolves the

configured Luna default and then rejects it.

• No project or machine-managed policy excludes Luna.

This indicates the collaboration tool has a separate model allowlist that does not match the authenticated Codex model catalog. It also means configuring Luna as the documented default breaks model-less spawning entirely.

I reproduced this on macOS with Codex Desktop's bundled CLI 0.146.0-alpha.9.2 and found a working V2 workaround for native Luna by using a named agent role (from reddit). This does not fix spawn_agent(model="gpt-5.6-luna"); the direct override still encounters the separate collaboration-model allowlist.

In ~/.codex/config.toml:

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

In ~/.codex/agents/executor_luna.toml:

name = "executor_luna"
description = "Luna executor for focused implementation, investigation, and verification tasks."
developer_instructions = "Complete the assigned task faithfully and report concrete results. Preserve unrelated changes, use available tools as needed, and surface uncertainty or failures."
model = "gpt-5.6-luna"
model_reasoning_effort = "high"

Then invoke the role rather than supplying a model override:

agents.spawn_agent(
  agent_type="executor_luna",
  fork_turns="none",
  ...
)

Important: remove/disable [agents] default_subagent_model = "gpt-5.6-luna". That default is resolved and validated before named-role application, so it still triggers the reported allowlist rejection and can break model-less spawning.

End-to-end verification from a fresh process:

• parent session model: gpt-5.6-sol
• a real agents.spawn_agent call created a child using agent_type="executor_luna"
• child rollout model/effort: gpt-5.6-luna / high
• child completed the requested sentinel
• OpenCodex, used as a loopback observer, recorded requestedModel, resolvedModel, and dispatched model all as gpt-5.6-luna, with HTTP 200

This demonstrates a role-path asymmetry: native Sol -> Luna works through V2 named-role application even though the direct model override remains rejected. I also tested a cross-provider custom model through the same role mechanism; it failed before provider dispatch with unreadable_encrypted_agent_task, so this evidence supports native Luna only, not arbitrary custom-provider subagents.

Reproduced again on Windows with Codex Desktop now actually running 0.147.0, and I can add an A/B comparison that appears to isolate this to the Desktop/app-server spawn path rather than the model catalog or Luna availability.

Environment

• Windows 11 x64
• Stable Desktop package: OpenAI.Codex 26.803.5235.0
• Desktop package status: Ok
• Codex Beta was uninstalled before the final reproduction
• Fresh Desktop-generated model cache reports:

client_version : 0.147.0

The fresh official catalog contains:

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

Clean-state reproduction

I had previously used a local catalog workaround which copied models_cache.json and changed only Luna's multi_agent_version from v1 to v2. That workaround makes Desktop accept Luna.

For this test I removed the model_catalog_json override entirely, renamed the old cache, and allowed Desktop to generate a brand-new official cache. The new cache was fetched by Desktop itself and reports client_version = 0.147.0.

I then fully terminated all ChatGPT.exe and codex.exe processes, verified none remained, relaunched Stable Desktop, and used a brand-new thread.

From a 5.6 parent, I requested exactly one child with:

model = gpt-5.6-luna
reasoning_effort = medium
fork_turns = none

Desktop still rejects it with:

Unknown model gpt-5.6-luna.
Available models are gpt-5.6-sol and gpt-5.6-terra.

No V1/V2 compatibility error is surfaced; Luna is rejected as though it is absent from the spawn allowlist despite being visibility=list in the current 0.147 catalog.

A/B: standalone CLI 0.147 succeeds on the same machine

I upgraded the separately installed CLI to:

codex-cli 0.147.0

Using the same official catalog (Luna remains list / v1), a Sol 0.147 CLI session successfully accepted:

model = gpt-5.6-luna
reasoning_effort = medium
fork_turns = none

and the child completed the requested sentinel successfully. There was no unknown-model, V1/V2, or capability error.

So on one host/account/catalog:

Standalone CLI 0.147.0  -> Sol -> Luna succeeds
Desktop/app-server 0.147 -> Sol -> Luna rejected as unknown model

This seems significant because 0.147 contains #36892 (support leaf models in Multi-Agent V2). The CLI behavior looks consistent with that change: Luna can remain v1 and be spawned as a leaf worker. The Desktop path still appears to construct or enforce a narrower allowlist containing only Sol/Terra.

Why I don't think this is only stale process/version skew

#37536 documents the same old Sol/Terra-only symptom when an old 0.146 app-server survives a 0.147 CLI update. I explicitly tested that hypothesis here:

1. fresh official cache generated by Desktop itself reports 0.147.0,
2. Luna is present as list / v1,
3. all Desktop/app-server processes were force-terminated,
4. a completely new Stable Desktop process was started,
5. a brand-new thread was used,
6. the rejection still reproduces.

So this reproduction appears distinct from a merely stale 0.146 app-server surviving an upgrade, although it may still share app-server-specific model-filtering code.

Additional diagnostic clue

The metadata-only workaround is particularly informative: copying the catalog and changing only Luna's

"multi_agent_version": "v1"

to

"multi_agent_version": "v2"

causes the same Desktop installation to accept Luna. Reverting to the official 0.147 catalog immediately restores the Unknown model / Sol+Terra-only behavior.

That suggests the Desktop spawn model allowlist is still filtering Luna based on the exact V2 catalog marker instead of allowing a visible V1 model as a leaf worker, while standalone 0.147 follows the new leaf-model behavior.

It may be worth checking whether the Desktop/app-server spawn_agent model validation/schema generation is using the same post-#36892 compatibility logic as the standalone CLI path.

Separate but possibly related top-level picker observation: in one Windows Desktop 26.803 / app-server 0.147.0 environment, setting the global default to gpt-5.6-luna + medium and then fully terminating/restarting all ChatGPT/codex processes caused the native Desktop picker to render Luna normally and restored Terra's reasoning choices. A fresh thread's persisted turn_context verified the actual route as Luna/medium. I documented the full A/B details here: https://github.com/openai/codex/issues/19694#issuecomment-5227617896

This is N=1 and I am not claiming it fixes the separate spawn_agent filtering bug; posting only as a picker-initialization/state clue.

Additional Windows Desktop reproduction with a custom-agent resolution clue:

Environment

• Windows 11 x64
• Codex Desktop package: OpenAI.Codex 26.803.5235.0
• Spawned child transcript reports bundled CLI 0.147.0-alpha.6.5
• Official catalog/cache: Sol list/v2, Terra list/v2, Luna list/v1
• ChatGPT authentication
• Global config originally contained:

``toml
[agents]
enabled = true
default_subagent_model = "gpt-5.6-luna"
default_subagent_reasoning_effort = "xhigh"
``

• Named agent files pin E.D.I.T.H./K.A.R.E.N. to Luna/xhigh and auditor to Sol/xhigh.

Reproduction

1. Direct native Desktop spawn with model=gpt-5.6-luna fails:

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

1. A model-less named-role spawn with agent_type=E.D.I.T.H. also fails with the same error.
2. More significantly, a model-less named-role spawn with agent_type=auditor, whose agent file pins model=gpt-5.6-sol, still fails with the Luna error.
3. The same auditor role succeeds immediately when the spawn call explicitly supplies model=gpt-5.6-sol.

This suggests agents.default_subagent_model is being validated before the named custom-agent file is resolved. An invalid/filtered default can therefore block every model-less custom role, including a role whose final pinned model is allowed.

A/B checks

• Top-level Luna succeeds under the same app/auth.
• Standalone Luna CLI succeeds.
• Native Desktop Terra child succeeds.
• In a standalone Sol CLI session, temporarily overriding only agents.default_subagent_model="gpt-5.6-terra" allowed a model-less agent_type=E.D.I.T.H. spawn to complete its sentinel.

Verified workaround

I then removed only these two global defaults:

default_subagent_model = "gpt-5.6-luna"
default_subagent_reasoning_effort = "xhigh"

The named agent files remained unchanged.

In a fresh Sol/high session with no model or effort override on child spawns:

• agent_type=E.D.I.T.H. resolved to actual runtime gpt-5.6-luna / xhigh / multi-agent v2
• agent_type=K.A.R.E.N. resolved to actual runtime gpt-5.6-luna / xhigh / multi-agent v2
• agent_type=default inherited actual runtime gpt-5.6-sol / high / multi-agent v2

These were verified from the persisted child turn_context, not from sentinel text alone. An already-open Desktop thread retained its old configuration and still failed, so a fresh thread/app reload is required.

Expected behavior

Resolve the named agent file first, then validate the effective child model; or make the Desktop/app-server leaf-model validation match standalone 0.147 behavior. A configured default should not block a custom role that pins a different valid model.

I did not modify models_cache.json or any agent model assignment, and did not substitute Terra for Luna.

Reproduced on another current Windows Codex Desktop installation with an exact native A/B control.

Environment

• Codex Desktop package: 26.803.5235.0
• Windows x64: 10.0.26200.0
• Relevant configuration:

[agents]
default_subagent_model = "gpt-5.6-luna"
default_subagent_reasoning_effort = "xhigh"

Native reproduction

The parent called:

spawn_agent(
  task_name="luna_bugreport_probe",
  fork_turns="none",
  model="gpt-5.6-luna",
  reasoning_effort="low",
  message="Read-only smoke test. Find README.md and return its path and first non-empty line."
)

The call failed immediately:

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

No child was created.

A/B control

An otherwise identical native call, changing only model to gpt-5.6-sol, succeeded. The Sol child was created, completed the same file lookup, returned the requested line, and appeared as completed in list_agents.

This confirms on a second Windows environment that the failure happens in the native Luna spawn validation/model allowlist before task execution; it is not caused by the task, repository, or context payload.

The exact gpt-5.6-luna ID is also usable through a direct Codex invocation on this installation, so general Luna access is available.

OpenAI feedback trace

The in-app feedback submission includes the Codex logs/session containing both the failed Luna call and the successful Sol control:

019fe9d1-c797-7bc2-a852-6fdec68a88c3

Please link this trace to the existing issue if the team has an internal bug ID.