[Release blocker] Backport #32749: stable Codex breaks model-routed subagent plugins

Severity and requested action

Please treat this as a stable release blocker and backport PR #32749 (merge commit ea1545628404e448347bae336771eaf649614105) to the next stable patch as soon as possible.

This is not a request to re-implement the base bug: #32749 was merged on 2026-07-13. The problem is that the fix has not reached the stable channel used by CLI/Desktop users and by plugins that depend on spawn_agent.

Verified release gap

| Channel | Version/ref | #32749 behavior present? |
|---|---|---|
| Current npm/GitHub stable | 0.144.4 / rust-v0.144.4 | No |
| Prerelease | rust-v0.145.0-alpha.9 | Yes |
| main | current | Yes |

The stable release was published on 2026-07-14, after #32749 merged, but its source still lacks expose_spawn_agent_model_overrides and the corresponding V2 schema logic:

• stable multi_agents_spec.rs
• alpha multi_agents_spec.rs
• stable release
• alpha release

Why this blocks plugin workflows

With Multi-Agent V2 defaults on stable, the model-visible spawn_agent schema omits model and reasoning_effort. Even if the runtime can accept those fields internally, a schema-driven controller cannot reliably issue them when they are absent from its tool definition. Children therefore inherit the parent configuration unless users apply fragile/invasive workarounds.

A concrete affected workflow is Superpowers 6.1.1 subagent-driven-development. Its model-selection contract says:

Always specify the model explicitly when dispatching a subagent.

It also assigns different model tiers to mechanical implementation, integration/debugging, architecture, and review work. Stable Codex makes that contract impossible to satisfy through the exposed V2 tool:

1. the plugin requires an explicit model for every dispatch;
2. stable spawn_agent does not expose a model parameter;
3. the controller must either violate the plugin contract, disable/degrade the workflow, or let every child inherit the often most-capable and most-expensive parent model.

This is not Superpowers-specific. Any orchestration plugin or skill that requires heterogeneous per-child model/effort routing is broken or materially degraded on the stable channel. The direct consequences are incorrect routing, higher latency, avoidable token/cost consumption, and inability to enforce plugin dispatch policy.

Scope clarification: what is and is not usable

This report does not claim that the entire Superpowers plugin fails to load or that every skill is unusable.

• Superpowers skills that do not require subagent model routing—such as brainstorming, test-driven development, systematic debugging, plan writing, and verification—can still run.
• Superpowers 6.1.1 subagent-driven-development cannot run according to its required contract on stable 0.144.4, because it mandates an explicit model on every dispatch while the model-visible V2 spawn_agent schema provides no model field.
• Other parallel/subagent workflows may still technically create children, but those children inherit the parent model when explicit routing is unavailable. That is degraded behavior, not correct operation: the intended model selection and cost controls cannot be enforced.
• The practical result is higher latency, avoidable token/cost consumption, and potentially using the most capable parent model for mechanical child tasks that the plugin explicitly assigns to cheaper/faster models.
• Restarting the app-server, rebooting the machine, or opening a fresh thread does not fix stable 0.144.4; the required schema change is absent from that stable binary.

Bottom line: Superpowers remains partially usable, but its core model-routed subagent-development workflow is not correctly usable on the current stable Codex release. The plugin must either violate its own dispatch policy, degrade to inherited parent models, or avoid that workflow until #32749 ships in stable.

Minimal reproduction on stable

1. Install @openai/codex@0.144.4.
2. Start a fresh GPT-5.6 Sol / Multi-Agent V2 session with default metadata-hiding behavior.
3. Inspect the model-visible collaboration.spawn_agent schema.
4. Observe that it exposes task_name, message, and fork_turns, but not model or reasoning_effort.
5. Attempt to run a plugin workflow that must select a model per child. There is no schema-valid way for the controller to honor that requirement.

Expected behavior, as implemented by #32749: model and reasoning_effort remain exposed by default when other spawn metadata is hidden, with overrides limited to partial/context-free forks.

Existing reports and why this issue is distinct

• #31814 reports the underlying forced-inheritance behavior and multiple real-world reproductions.
• #32430 reports the omitted schema fields directly.
• #32749 implements and tests the focused fix.
• #32831 is a separate custom-role precedence issue after model overrides become callable.

Those cover the base defect and a follow-on bug. This issue tracks the stable packaging/backport gap: users on the supported stable channel still do not receive the already-merged fix.

Requested acceptance criteria

• Backport #32749 to the active stable branch and publish a 0.144.x patch (or the earliest stable equivalent).
• In a fresh default Multi-Agent V2 session, verify that spawn_agent exposes model and reasoning_effort while the remaining hidden metadata stays hidden.
• Verify the same schema through both standalone CLI and Desktop/app-server surfaces.
• Add a release-note entry so plugin authors know which stable version restores model-aware dispatch.