Skip to content

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 #3875

Description

@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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:agentsSub-agents, fleet, autopilot, plan mode, background agents, and custom agentsarea:modelsModel selection, availability, switching, rate limits, and model-specific behavior

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions