GPT-5.6: managed multi_agent_v2=false causes reserved collaboration.spawn_agent schema error

[yoonpooh]

Summary

With GPT-5.6 (gpt-5.6-sol), LazyCodex 4.16.0 can make every turn fail before the model responds by re-inserting a managed [features.multi_agent_v2] enabled = false section on session start. Removing the entire LazyCodex-managed section immediately restores normal turns.

The failure is:

Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.

Environment

• LazyCodex version: 4.16.0
• Codex CLI version: 0.144.0
• Model: gpt-5.6-sol
• OS: macOS 27.0, arm64
• Surface: Codex Desktop session
• Install method: Codex plugin cache / LazyCodex OMO plugin
• Relevant managed config:

# Managed by LazyCodex: multi_agent_v2 is re-disabled on every Codex session start
# because enabling it fails every turn with HTTP 400 (openai/codex#26753).
# Opt out: LAZYCODEX_CONFIG_MIGRATION_DISABLED=1 (or OMO_CODEX_CONFIG_MIGRATION_DISABLED=1).
[features.multi_agent_v2]
enabled = false
hide_spawn_agent_metadata = false
max_concurrent_threads_per_session = 1000

Repository Decision

• Target repository: code-yeongyu/lazycodex
• Why this belongs here: the observed trigger is a configuration block that LazyCodex writes and re-applies on every SessionStart. Removing only that LazyCodex-managed block fixes the session.
• LazyCodex evidence: plugins/omo/scripts/migrate-codex-config/multi-agent-v2-guard.mjs explicitly removes model-resolved behavior and appends enabled = false when the section is absent.
• Upstream Codex evidence: current Codex resolves the multi-agent version from model metadata before falling back to local feature flags (session/mod.rs). The stable V1 and under-development V2 paths also expose different tool surfaces (config/mod.rs). This model-aware behavior makes a blanket session-start override unsafe.
• Related upstream issues: MultiAgentV2 encrypted spawn_agent schema returns 400: model not configured for encrypted tool use openai/codex#26753 covers the older encrypted V2 schema failure that motivated this workaround; [CLI] GPT-5.5 forces MultiAgentV2 despite disable and hides documented custom-agent controls openai/codex#31097 covers model metadata forcing V2 despite a local disable. Neither covers LazyCodex continuing to inject the now-harmful disable for GPT-5.6.

Reproduction

1. Use LazyCodex 4.16.0 with Codex CLI 0.144.0 and model gpt-5.6-sol.
2. Start a session with LazyCodex config migration enabled (the default).
3. Confirm that LazyCodex has inserted the managed [features.multi_agent_v2] section shown above with enabled = false.
4. Send any prompt.
5. Observe that the request is rejected before the model responds with the reserved collaboration.spawn_agent schema error.
6. Remove the entire LazyCodex-managed [features.multi_agent_v2] block and start a new session.
7. Send the same kind of prompt and observe that the turn succeeds normally.

Expected Behavior

LazyCodex should not write a feature override that makes GPT-5.6 sessions unusable. Model-specific multi-agent defaults should be left intact unless LazyCodex has verified that an override is required and compatible with the selected Codex/model combination.

Actual Behavior

LazyCodex re-adds enabled = false on every session start. With GPT-5.6, this produces a tool-schema mismatch against the model-reserved collaboration.spawn_agent function and causes every turn to fail:

Invalid Value: 'tools'. Function 'collaboration.spawn_agent' is reserved for use by this model and must match the configured schema.

Deleting the managed section fixes the problem.

Evidence

• Toggle proof from the affected environment:
  • Managed section present: every turn fails with the exact schema error above.
  • Managed section deleted: turns work normally.
• Local version fingerprint: codex-cli 0.144.0, LazyCodex 4.16.0, gpt-5.6-sol, macOS arm64.
• Latest LazyCodex source at 58d34daae803787ce82507345cfc5b1158c033a4 still unconditionally calls appendDisabledSection() when no V2 section exists.
• Latest upstream Codex source at d72d669ca727a26765315ffe03db3dd2594d9b91 has model-aware multi-agent version selection and a dedicated namespaced V2 collaboration tool surface.
• No matching issue was found in code-yeongyu/lazycodex for collaboration.spawn_agent, the reserved-schema error, or GPT-5.6 plus multi_agent_v2.

Root Cause

The LazyCodex workaround for openai/codex#26753 is now stale for GPT-5.6. forceDisableMultiAgentV2() materializes an explicit enabled = false section on every session start, overriding the absence of a setting that Codex can otherwise resolve per model. GPT-5.6 reserves collaboration.spawn_agent with a specific schema; with the managed override present, the client sends a conflicting schema and the API rejects the entire turn. Removing the managed section toggles the failure off, so the LazyCodex migration is the confirmed trigger. The exact server-side schema-selection details remain upstream, but clean operation without the LazyCodex-managed block shows that no upstream change is required for the observed workaround.

Proposed Fix

1. Stop unconditionally appending [features.multi_agent_v2] enabled = false on every session start.
2. Remove previously generated sections identified by the openai/codex#26753 managed marker when running on Codex/model combinations that use the reserved collaboration schema (at minimum GPT-5.6).
3. Prefer leaving multi_agent_v2 unset so Codex can apply model metadata. Do not overwrite an explicit user choice.
4. Add a migration regression test showing that GPT-5.6-compatible configurations do not receive the stale disable block.

Verification Plan

• Start a fresh GPT-5.6 session after migration and confirm no managed disable block is inserted.
• Send a normal prompt and verify it completes without a tools schema error.
• Invoke collaboration.spawn_agent and confirm the schema matches the model-reserved definition.
• Verify older supported models and the existing MultiAgentV2 encrypted spawn_agent schema returns 400: model not configured for encrypted tool use openai/codex#26753 workaround path do not regress.
• Restart Codex and confirm the harmful block is not re-created.

---

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

[foxion37]

Upstream fix proposed in code-yeongyu/oh-my-openagent#6004 (model-aware multi_agent_v2 guard). LazyCodex can pick this up on the next marketplace sync after merge.

[code-yeongyu]

Fixed upstream in code-yeongyu/oh-my-openagent#6004 (merged to dev, merge commit 8afc078a69c).

The guard is now model-aware: when the effective session model (SessionStart hook model wins over the config.toml default) resolves to multi_agent_version: "v2" in CODEX_HOME/models_cache.json — or the catalog is missing but the model is gpt-5.6* — the migration clears the managed enabled = false block and its comments instead of re-writing it, removes agents.max_threads (rejected while V2 is active), and leaves V2 unset so Codex follows model metadata.

One extra poison key was found during verification on codex-cli 0.144.1 + gpt-5.6-sol: hide_spawn_agent_metadata = false (written by OMO installers <= 4.15.x to expose agent_type) also mismatches the reserved collaboration.spawn_agent schema and 400s every turn — the guard now removes it on the V2-preferred path too.

Verified end-to-end on a machine that reproduced this exact bug: after the migration heals ~/.codex/config.toml, codex exec --model gpt-5.6-sol "hi" completes normally, a second SessionStart is a byte-identical no-op (no config tug-of-war), and gpt-5.5 sessions still work.

This lands here on the next stable release's automatic marketplace sync.

[code-yeongyu]

Shipped in v4.16.2 — the marketplace payload here now carries the model-aware guard (plugins/omo/scripts/migrate-codex-config/multi-agent-v2-guard.mjs clears the managed disable + hide_spawn_agent_metadata = false on V2 models instead of re-writing it).

Verified end-to-end on a machine that reproduced this exact report: after codex plugin marketplace upgrade sisyphuslabs (or npx lazycodex-ai@latest install), the first session start auto-repairs ~/.codex/config.toml and codex exec --model gpt-5.6-sol "hi" completes normally; subsequent session starts are byte-stable (no config tug-of-war).

Follow-up hardening landed on dev for the next release: the installer itself is now V2-aware too (oh-my-openagent#6008), and CLI entry guards are symlink-tolerant so hooks can't silently no-op on symlinked plugin caches.

Note: LazyCodex auto-update has a 24h throttle — updating manually is strongly recommended.