Explore agent fails with 'int too big to convert' when MCP tools are present (haiku model)

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 ." })
``

1. 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:

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

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

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

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

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

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

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

1. 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

| Agent | Default model | Status |
|-------|--------------|--------|
| Explore | "haiku" | Fails |
| Plan | "inherit" | Works |
| general-purpose | (inherits) | Works |
| statusline-setup | "sonnet" | Works |

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)