Unable to spawn subagents with `mai-code-1-flash-picker` when the main agent model is `gpt-5.4` or `gpt-5.5` with `deferTools: never` config

[hope68korea]

Describe the bug

Summary

Spawning a subagent with the mai-code-1-flash-picker model appears to break only when deferTools: never is set for some MCP server configs.

At first this looked like a model-pairing issue between a main conversation running on gpt-5.4 / gpt-5.5 and a subagent using mai-code-1-flash-picker. After more testing, the more accurate trigger seems to be the newer deferTools: never MCP configuration rather than the subagent model alone.

Environment

• GitHub Copilot CLI 1.0.64-1
• Main model: reproduced from gpt-5.4 / gpt-5.5
• Subagent model: mai-code-1-flash-picker
• Interface: GitHub Copilot CLI / agent tool flow
• Additional condition: deferTools: never enabled for some MCP configs

Actual Result

When deferTools: never is enabled on affected MCP configs, spawning the subagent does not behave correctly. In my testing this showed up as a tool failure such as:

✗ Execution failed: CAPIError: 400 Tool 'tool_search' is not supported with gpt-5. (Request ID: C57D:3931E0:32D4049:3A7FACE:6A367C5C)

In some cases the spawn path may also return no useful subagent output instead of a normal success/failure response.

Steps to reproduce the behavior

1. Configure one or more MCP servers with deferTools: never.
2. Start a session using a main model such as gpt-5.4 or gpt-5.5.
3. Try to spawn a subagent with model: "mai-code-1-flash-picker".
4. Observe the failed or empty subagent execution behavior.

Expected behavior

The subagent flow should either:

1. spawn successfully with mai-code-1-flash-picker, or
2. fail immediately with a clear validation or compatibility error that explains the unsupported configuration.

Additional context

• Before isolating deferTools: never, this appeared to be a parent/subagent model compatibility issue.
• The newer finding is that the problematic behavior only occurs when deferTools: never is enabled for some MCP configs.
• That suggests the real issue is likely in tool resolution / tool exposure during subagent startup under this MCP configuration path.

thanks