›_ Codex Issues
Codex Issues / #34166

spawn_agent model override description truncates valid catalog models to five

Open 💬 4 comments Opened Jul 19, 2026 by iron-water

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.

View original on GitHub ↗

4 Comments

Kevinjohn · 1 month ago

The spawn_agent description currently presents a capped five-model list as exhaustive even when additional catalog models remain valid.

Confirmed against current main at 7844386e3d.

The cap itself is useful because it keeps model-visible tool descriptions bounded. The issue is that spawn_agent_models_description() applies .take(MAX_SPAWN_AGENT_MODEL_OVERRIDES) before it can tell the model that entries were omitted.

I have a focused patch prepared:

  • Preserve the existing five-entry cap.
  • Detect whether the eligible picker-visible model list exceeded that cap before truncating it.
  • Only when truncation occurs, append: “This list is truncated to 5 entries. Other catalog models may also be valid; try an explicit override before declaring a model unavailable.”
  • Extend the existing six-model regression test to require that disclosure while continuing to verify that the sixth model is not injected into the description.

Descriptions for catalogs containing five or fewer eligible models remain unchanged.

Actual screenshots

Before — the existing six-model test fails because the model-visible description omits the required non-exhaustive-list guidance:

!Before: truncated model list has no disclosure

After — the same focused test passes while the five-entry cap remains in place:

!After: truncated model list includes disclosure

Validation:

  • Focused six-model regression: passes.
  • All multi_agents_spec tests: 11 passed.
  • just fix -p codex-core: passes.
  • just fmt: passes.

---

I have a PR ready if issue accepted

ignatremizov · 1 month ago

Share your fork commit SHA/branch

Kevinjohn · 1 month ago

Thanks — the patch is ready and pushed.

Actual before — upstream implementation at 2deed3fb9c:

!Before: regression assertion fails because the five-entry model list has no truncation disclosure

Actual after — patch at 31ed6acb7ce68eecfe039c6230bb8d2993094587:

!After: the same regression assertion passes with the truncation disclosure

GitHub's compare page reports that opening pull requests is limited to repository collaborators, so I cannot submit it directly. The branch is ready for review or cherry-pick, and I can update it immediately if you would like any changes.

alsi-lawr · 1 month ago

Why are these being limited to 5? What's the point of "keeping it bounded"? Are you expecting users to having some ridiculous number of models? This is all tightly controlled in the config regardless, and protecting the user from themself here seems like a massive overreach with material downsides.