claude-code - 💡(How to fix) Fix Explore agent fails with 'int too big to convert' when MCP tools are present (haiku model) [1 comments, 2 participants]

Bug

Spawning an Explore subagent fails 100% of the time with:

API Error: 400 {"type":"error","error":{"type":"invalid_request_error",
"message":"tools.70.custom.input_schema: int too big to convert"}}

The tool index varies by session (seen tools.41 and tools.70) depending on how many MCP servers are connected.

Repro

1. Have several MCP servers configured (I had ~10 local + remote servers, ~217 total tools)
2. Run any Explore agent:

   Agent({ subagent_type: "Explore", prompt: "list files in ." })

3. Fails with int too big to convert

Workaround: Override the model — Agent({ subagent_type: "Explore", model: "sonnet", prompt: "..." }) works fine.

Root cause

The Explore agent hardcodes model: "haiku" in its definition (cli.js):

Kp = {
  agentType: "Explore",
  model: "haiku",          // <-- haiku
  disallowedTools: [Agent, ExitPlanMode, Edit, Write, NotebookEdit],
  ...
}

The Plan agent, which has identical tool exclusions, uses model: "inherit" and works fine:

dh8 = {
  agentType: "Plan",
  model: "inherit",         // <-- inherits parent (opus/sonnet)
  disallowedTools: [Agent, ExitPlanMode, Edit, Write, NotebookEdit],
  tools: Kp.tools,
  ...
}

The haiku API endpoint rejects large integers in tool input_schema fields that opus/sonnet accept. The offending value is 9007199254740991 (Number.MAX_SAFE_INTEGER), which appears in the Read tool's schema for offset and limit parameters.

How the large integer gets there

1. The Read tool defines offset and limit using Zod:

   offset: y.number().int().nonnegative().optional()
   limit:  y.number().int().positive().optional()

2. .int() in Zod 4 calls $K1() which sets format: "safeint"

3. The safeint format maps to [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER] in Zod's NUMBER_FORMAT_RANGES:

   w71 = {
     safeint: [Number.MIN_SAFE_INTEGER, Number.MAX_SAFE_INTEGER],
     int32:   [-2147483648, 2147483647],
     uint32:  [0, 4294967295],
     ...
   }

4. The onattach hook writes these into the Zod bag:

   w.minimum = -9007199254740991;
   w.maximum =  9007199254740991;  // <-- this overflows

5. The JSON Schema serializer emits { "type": "integer", "maximum": 9007199254740991 }

6. The haiku API endpoint rejects this integer (likely a 32-bit int limit in the validator), while opus/sonnet endpoints accept it.

Affected built-in agent types

Any custom agent routed to haiku will also fail (e.g. custom agents with model: "haiku" in their definition).

Suggested fix

Either:

• API side: Fix haiku's input_schema validator to accept 64-bit integers (matching opus/sonnet behavior)
• Client side: Strip or cap maximum/minimum values in tool schemas before sending to the API (e.g., remove Zod's safeint bounds since they're not semantically meaningful for the API)

Environment

• Claude Code: 2.1.108
• macOS Darwin 24.1.0
• ~217 tools (10 built-in + deferred + ~186 MCP)
• MCP servers: chrome-devtools, ccusage, shadcn, playwright, compress, miro-tools, r2, claude-in-chrome, plus several claude.ai remote MCPs (Neon, Mercury, Gmail, Google Calendar, Linear, Cloudflare, Stripe, Miro)