spawn_agent model override description truncates valid catalog models to five
Codex App version
26.715.4045 (bundled codex-cli 0.145.0-alpha.18)
Platform
Microsoft Windows NT 10.0.26200.0 x64
Issue
The collaboration.spawn_agent tool description labels a list as "Available model overrides", but the generated description is capped at five entries. When a sixth catalog model is valid and callable, it is omitted without any indication that the list is non-exhaustive.
This causes the parent agent to confidently report that the omitted model is unavailable, even though an explicit spawn_agent call succeeds.
This is distinct from #34024: the omitted model is not rejected at runtime in this reproduction. It is accepted and runs successfully. It is also a narrower follow-up to #32031: even when model override metadata is visible, truncating the advertised model list still produces incorrect model behavior.
Reproduction
- Use multi-agent v2 with a model catalog containing six models eligible for v2 (
multi_agent_version = "v2", visible and API-supported). - Start a fresh Codex Desktop session after restarting the app.
- Inspect the model-visible
spawn_agentdescription. Only five model overrides are advertised. - Ask the parent to use the omitted sixth model. The parent may refuse and state that it is not in the callable model list.
- Explicitly call
spawn_agentwith the omitted model,fork_turns = "none", and a supported reasoning effort. - The child is created successfully and returns normally.
Observed live probe:
spawn_agent(model=<omitted sixth model>, fork_turns="none", reasoning_effort="low")
=> child created successfully
=> expected probe marker returned
Expected behavior
Either:
- advertise every model that runtime validation will accept, or
- label the displayed list as non-exhaustive and tell the model to attempt an explicit override before declaring a model unavailable.
The tool description and runtime validator should use the same source of truth.
Actual behavior
The description presents five entries as the available overrides, while runtime validation accepts an additional catalog model. The mismatch leads to false refusals and unnecessary fallback to a different model.
Additional information
The local catalog entry was verified as v2-compatible, visible, and API-supported. A full Desktop restart did not change the five-entry description. No provider URL, credentials, or local catalog paths are included here.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗