spawn_agent model override description truncates valid catalog models to five

Start at the multi-agent v2 collaboration.spawn_agent tool-description generation and its runtime model validation, then compare how each obtains the eligible model list. Reproduce with six visible, API-supported catalog models and verify that every accepted model is advertised or that the list is clearly marked non-exhaustive without causing false refusals.

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

1. Use multi-agent v2 with a model catalog containing six models eligible for v2 (multi_agent_version = "v2", visible and API-supported).
2. Start a fresh Codex Desktop session after restarting the app.
3. Inspect the model-visible spawn_agent description. Only five model overrides are advertised.
4. Ask the parent to use the omitted sixth model. The parent may refuse and state that it is not in the callable model list.
5. Explicitly call spawn_agent with the omitted model, fork_turns = "none", and a supported reasoning effort.
6. 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.