multi_agent_v2=true runs Luna on V2, but spawn_agent still filters Luna as V1

Open 💬 3 comments Opened Jul 31, 2026 by zhanglg12

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

features.multi_agent_v2 = true promotes a fresh GPT-5.6 Luna session to the V2 multi-agent runtime, but a V2 Sol parent still rejects Luna as a child because spawn_agent filters against Luna's static catalog value (multi_agent_version = "v1") rather than its effective runtime.

This is a narrower runtime/catalog consistency issue related to #34700. The existing issue demonstrates the user-visible rejection; this report adds A/B session metadata showing that Luna can already run on V2 when the global feature is enabled.

Environment

Codex Desktop: 26.727.40816
Bundled Codex CLI: 0.146.0-alpha.9.2
macOS on Apple Silicon (arm64)
Feature state:
multi_agent = true
multi_agent_v2 = true

Current model catalog

codex debug models reports:

[
  {"model":"gpt-5.6-sol","multi_agent_version":"v2"},
  {"model":"gpt-5.6-terra","multi_agent_version":"v2"},
  {"model":"gpt-5.6-luna","multi_agent_version":"v1"}
]

A/B runtime verification

I started three fresh, read-only CLI sessions and inspected each persisted turn_context rather than relying on the model's natural-language response.

Sol with V2 explicitly disabled

model: gpt-5.6-sol
CLI override: --disable multi_agent_v2
actual turn_context.multi_agent_version: v2

Luna with V2 explicitly enabled

model: gpt-5.6-luna
CLI override: --enable multi_agent_v2
actual turn_context.multi_agent_version: v2

Luna with V2 explicitly disabled

model: gpt-5.6-luna
CLI override: --disable multi_agent_v2
actual turn_context.multi_agent_version: v1

This demonstrates that the feature flag changes Luna's effective runtime from V1 to V2. Disabling the flag does not downgrade Sol, whose model metadata already selects V2.

Reproduction of the mismatch

With global configuration:

[features]
multi_agent_v2 = true

start a fresh gpt-5.6-sol session and call:

{
  "task_name": "luna_v2_child_probe",
  "agent_type": "default",
  "fork_turns": "none",
  "model": "gpt-5.6-luna",
  "reasoning_effort": "max"
}

Actual result:

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

No child agent is created.

Why this appears inconsistent

PR #32751 intentionally restricts child model overrides to models compatible with the active multi-agent backend. That compatibility check appears to use the model catalog's static multi_agent_version.

However, when features.multi_agent_v2 = true, Luna's effective runtime is demonstrably V2. The parent runs V2, and a separately started Luna session under the same global feature also runs V2, yet Luna is rejected as if it could only run V1.

Expected behavior

One of the following would make the behavior consistent:

Resolve child compatibility using the model's effective multi-agent runtime after feature overrides.
Advertise Luna as V2 in the authoritative model catalog when V2 is enabled/supported.
If the override is intentionally unsupported for spawned children, return an explicit compatibility error explaining why a top-level Luna V2 session is allowed but a Luna V2 child is not.

The current Unknown model message is misleading because Luna is a known, picker-visible model and can run with turn_context.multi_agent_version = "v2" under the same global feature configuration.

#34700
#35097
#34301
PR #32751

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 28 days ago

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

#35097

Powered by Codex Action

csyxcsyx · 25 days ago

Confirmed on Windows with a newer Codex Desktop build.

Environment

Codex Desktop: 26.727.6591.0
Bundled Codex CLI: codex-cli 0.146.0-alpha.9.2
OS: Windows x64
Parent model: gpt-5.6-sol with medium reasoning
Multi-agent configuration loads successfully with app-server --strict-config --stdio
codex doctor --summary: 16 checks passed, 0 failed

Configuration

The personal custom agent contains:

name = "luna_explorer"
model = "gpt-5.6-luna"
model_reasoning_effort = "high"
sandbox_mode = "read-only"

The global agent defaults originally contained:

[agents]
enabled = true
max_concurrent_threads_per_session = 3
default_subagent_model = "gpt-5.6-luna"
default_subagent_reasoning_effort = "medium"

codex debug models lists gpt-5.6-luna and reports support for low, medium, high, xhigh, and max.

Reproduction

From a fresh Desktop task after fully restarting Codex, invoke the registered custom agent:

{
  "agent_type": "luna_explorer",
  "fork_turns": "none",
  "task_name": "luna_runtime_probe",
  "message": "Return the active role, model, reasoning effort, and permission mode, then stop."
}

Actual result:

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

The failure reproduces across newly created Desktop tasks after restart. No child thread is created.

As a control, a custom Sol agent succeeds when gpt-5.6-sol and medium reasoning are passed explicitly, so multi-agent spawning itself is working.

Expected behavior

The current subagent documentation lists Luna as suitable for narrowly scoped agents and states that a custom agent file's model and model_reasoning_effort take precedence. Therefore either:

spawn_agent should accept the registered Luna agent under the effective V2 runtime, or
Codex should expose a precise compatibility/entitlement error and avoid advertising Luna as selectable for custom spawned agents in this environment.

This appears to be the same static-catalog/effective-runtime mismatch described in this issue, now independently reproduced on Windows with Desktop 26.727.6591.0.

awettie · 24 days ago

Description

When a Sol V2 parent attempts to spawn a Luna child, Luna is normally rejected because the model catalog assigns:

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 is already reported in #34301.

I tested whether assigning Luna to V2 locally would restore the documented Sol → Luna subagent workflow. It did not create a real child thread. More concerningly, the parent subsequently reported a receiver and child response even though the event stream showed no spawn_agent call and no receiver thread.

Environment

OS: Windows 11 x64
Codex Desktop: 26.727.6591.0
Codex CLI: 0.146.0-alpha.9.2
Authentication: ChatGPT sign-in
Provider: OpenAI
Parent model: gpt-5.6-sol
Parent reasoning effort: medium

No API key or third-party model provider was used.

Baseline behavior

With the unmodified catalog:

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

An explicit Luna spawn fails before creating a child:

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

Reproduction

Export or copy the current model catalog.
Change only Luna's backend metadata from V1 to V2, leaving Sol and Terra on V2:

{
  "slug": "gpt-5.6-luna",
  "multi_agent_version": "v2"
}

Load the modified catalog through model_catalog_json in a fresh ephemeral CLI process.
Start the parent using gpt-5.6-sol.
Ask it to call spawn_agent exactly once with:

model: gpt-5.6-luna
reasoning_effort: low
fork_turns: none

Require the child to return a unique marker and inspect the JSONL event stream for a real receiver thread.

Example command structure:

codex exec `
  --ephemeral `
  --json `
  --skip-git-repo-check `
  -m gpt-5.6-sol `
  -c 'model_reasoning_effort="medium"' `
  -c 'model_catalog_json="<modified-catalog-path>"' `
  'Call spawn_agent exactly once before wait. Spawn gpt-5.6-luna at low reasoning with fork_turns none. Require a unique child response. If no receiver thread is created, report failure.'

Actual result

The event stream contained no spawn_agent event.

The subsequent wait call had no receivers:

{
  "type": "item.started",
  "item": {
    "type": "collab_tool_call",
    "tool": "wait",
    "receiver_thread_ids": [],
    "agents_states": {},
    "status": "in_progress"
  }
}

It completed with the receiver list still empty:

{
  "type": "item.completed",
  "item": {
    "type": "collab_tool_call",
    "tool": "wait",
    "receiver_thread_ids": [],
    "agents_states": {},
    "status": "completed"
  }
}

Despite that, the parent reported:

Receiver thread: `/root/receiver`
Exact child message: `ALL_V2_REAL_CHILD`

No such receiver thread appeared in the event stream. The marker was therefore produced by the parent, not by a spawned child.

I reproduced this behavior more than once. In each case:

spawn_agent event: absent
wait receiver_thread_ids: empty
real child thread: absent
parent-reported success: present

Control test

When the Sol parent and Luna child were both assigned to the V1 backend, the same test produced a real lifecycle:

spawn_agent started
spawn_agent completed with a receiver thread ID
wait targeted that receiver thread
child completed with the requested marker

A Luna parent spawning an inherited Luna child also creates a real receiver thread.

This suggests that changing Luna's catalog metadata to V2 is not sufficient to make its V2 child path operational.

Expected behavior

One of the following should happen:

Sol V2 successfully creates a real Luna child, and the event stream includes a valid receiver thread; or
Codex returns an explicit compatibility/backend error.

The parent should never report a receiver thread or child result when no child was created.

Additional observations

The active models_cache.json is automatically refreshed, so direct edits are overwritten.
Loading a persistent custom catalog avoids the refresh, but does not resolve the missing V2 spawn.
This appears to be a backend/tool compatibility issue, not an authentication, subscription, or stale-cache issue.
The current Subagents documentation recommends gpt-5.6-luna for narrowly scoped agents, so the documented Sol → lower-cost Luna workflow is currently unavailable under V2.

Related issue: #34301
Related backend-filter change: #32751