[BUG] CLI crashes (exit code 1) on unhandled McpError -32001 AbortError during tool_use

Summary

The Claude Code CLI (v2.1.142) crashes with exit code 1 when an MCP server disconnects or aborts during an active tool_use call. The McpError: MCP error -32001: AbortError: The operation was aborted propagates as an unhandled exception instead of being caught and recovered from gracefully. This causes cascading session crashes when running multiple sessions with many MCP servers.

Environment

• OS: Windows 11, x64, 32 GB RAM
• Claude Desktop: 1.7196.3
• Claude Code CLI: 2.1.142 (Bun-based)
• MCP servers: 13 configured (stdio + HTTP)
• Sessions: 2-3 concurrent local sessions
• Permission mode: bypassPermissions

Steps to Reproduce

1. Configure 10+ MCP servers in ~/.claude.json
2. Open 2-3 sessions in Claude Desktop
3. Use the sessions actively (tool calls across multiple MCP servers)
4. Wait for any MCP server to become slow or unresponsive (more likely under memory pressure with many servers × sessions)
5. CLI crashes with exit code 1 when it tries to call that server

Error Output

From Desktop main.log, the one crash where the CLI diagnostic was captured:

[CCD CycleHealth] local_c7094bd8 cli_execution_error (error_during_execution):
  [ede_diagnostic] result_type=user last_content_type=n/a stop_reason=tool_use;
  McpError: MCP error -32001: AbortError: The operation was aborted.
    at D (B:/~BUN/root/src/entrypoints/cli.js:99:25115)
    at <anonymous> (B:/~BUN/root/src/entrypoints/cli.js:99:25373)
    at abort (unknown)
    at de1 (B:/~BUN/root/src/entrypoints/cli.js:942:3782)
    at abort (unknown)
    at de1 (B:/~BUN/root/src/entrypoints/cli.js:942:3782)
    at abort (unknown)
    at <anonymous> (B:/~BUN/root/src/entrypoints/cli.js:19287:2089)
    at processTicksAndRejections (native:7:39)

Most crashes only show the Desktop-side error (no CLI diagnostic):

Error: Claude Code process exited with code 1
    at BPi.getProcessExitError (index.js:406:8122)
    at ChildProcess._handle.onexit (node:internal/child_process:295:12)

Observed Behavior

• 84 exit-code-1 crashes in a single day across 2-3 sessions
• Crash durations vary: 27s, 48s, 80s, 122s, 141s, 162s, 206s, 229s, 238s, 273s (not time-based; depends on when a tool_use hits a failing MCP server)
• Each crash triggers a re-warm (spawning new MCP servers), creating a crash loop
• reason=system_error in CycleHealth for most crashes; one captured as cli_execution_error revealing the McpError stack
• Reducing MCP server count from 19 to 13 dramatically reduced crash frequency (from every ~75s to stable)

Expected Behavior

When an MCP server disconnects or aborts during a tool_use:

1. The CLI should catch the McpError -32001 AbortError
2. Report the tool failure to the model (e.g., as a tool_result with is_error=true)
3. Let the model decide how to proceed (retry, use alternative, inform user)
4. Not crash the entire session

Additional Context

• The McpError -32001 code corresponds to MCP's generic server error / timeout
• Windows also reported 4 AppHangTransient events for claude.exe, suggesting the process hangs before crashing
• The Desktop's onQuitCleanup(mcp-shutdown) also throws TypeError: Cannot read properties of undefined (reading 'isDestroyed') after crashes, suggesting the cleanup path has a related bug
• EBUSY: resource busy or locked errors on chrome-native-host.exe copy during startup suggest file locking issues between concurrent sessions

Workaround

Reduce the number of MCP servers to minimize the probability of any server failing during a tool_use. In our case, going from 19 servers (×2 sessions = 38 server groups) to 13 servers stopped the crash loop.