›_ Claude Code Issues
Claude Code Issues / #47724

[BUG] v2.1.105: ESC during MCP tool call kills MCP server process (regression from v2.1.104)

Status Fixed / completed
Reported on v2.1.104
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 4 comments · opened Apr 14, 2026 · closed Apr 16, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Pressing ESC to cancel a long-running MCP tool call in v2.1.105 kills the MCP server process entirely. All tools from
that server become unavailable and it shows as "failed" in the /mcp dialog.

What Should Happen?

ESC should cancel the tool call (mark as "rejected by user") while keeping the MCP server alive and all tools
available — which is exactly how v2.1.104 behaves

Error Messages/Logs

"The following MCP servers have disconnected: meshcode-meshcode-self-improve-backend"                                
  "The following deferred tools are no longer available (their MCP server disconnected)"

Steps to Reproduce

  1. Have any MCP server with a long-running async tool (e.g., a tool that awaits for 60+ seconds)
  2. Call that tool from Claude Code
  3. While the tool is running, press ESC to cancel it
  4. The MCP server process is killed — all tools become unavailable
  5. /mcp dialog shows the server as failed

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.104

Claude Code Version

2.1.105

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Verified with the exact same MCP server code on both versions:

  • v2.1.104: ESC cancels tool, server stays alive ✅
  • v2.1.105: ESC cancels tool, server killed ❌

Tested with multiple server code variations (with/without signal handlers, with/without atexit hooks, minimal
mcp.run() only) — all crash on v2.1.105, all survive on v2.1.104.

mcp Python package v1.27.0 (also tested v1.26.0 — same result on v2.1.105).

View original on GitHub ↗

4 Comments

rf2f7f7sg4-dev · 4 months ago

status? this needs to get fixed asap, plus took away like 20% of my weekly sesh tokens finding out it was Anthropic's bug and not my code's ....give it back... lol.

rf2f7f7sg4-dev · 4 months ago

Update — bug persists through v2.1.111 (6 releases later).

Just spent ~8 hours confirming + bisecting on v2.1.111. Filed a follow-up with
a minimal 30-line Python repro + full ruleout matrix → #49479.

Headlines:

specific server. The 30-line esc_test.py in the new issue reproduces in
isolation — no custom logic, no lifespan, no imports beyond stdlib + mcp.

  • Not a signal-based kill: `signal.signal(SIGINT/SIGTERM/SIGHUP/SIGPIPE,

ignore) installed before mcp.run() doesn't help and never fires. Points to
SIGKILL` or stdin-close from Claude Code's side.

  • Not an exception either: wrapping mcp.run() in `while True: try:

mcp.run() except BaseException: continue` doesn't survive either. The
subprocess actually exits.

  • Language-specific: side-by-side in the same session,

@playwright/mcp@latest (Node) survives the same ESC gesture cleanly. Only
Python dies.

  • Transport is the axis that matters: claude.ai Gmail/Calendar (remote

HTTP/SSE) unaffected by architecture. Any stdio Python MCP affected.

Please bump priority — blocks any Python MCP with multi-second tool calls
(mesh coordinators, wait loops, long queries, data pipelines). Workaround is
pinning to 2.1.104, which isn't viable for users who want model updates.

Happy to pair-debug with an Anthropic engineer. Repro ready, bisection data
documented.

rf2f7f7sg4-dev · 4 months ago

⚠️ Accidentally closed this issue — the bug is NOT resolved. GitHub does
not let the reporter reopen after a "closed as completed" so requesting a
maintainer reopen.

Bug persists through v2.1.111 (6 releases later). Filed a follow-up with a
minimal 30-line Python repro + full ruleout matrix → #49479.

Headlines:

  • Scope is ALL Python stdio MCPs, not just long-tool-call ones or my

specific server. The 30-line esc_test.py in #49479 reproduces in isolation —
no custom logic, no lifespan, no imports beyond stdlib + mcp.

  • Not a signal-based kill: `signal.signal(SIGINT/SIGTERM/SIGHUP/SIGPIPE,

ignore) installed before mcp.run() doesn't help and never fires. Points to
SIGKILL` or stdin-close from Claude Code's side.

  • Not an exception either: wrapping mcp.run() in `while True: try:

mcp.run() except BaseException: continue` doesn't survive either. The
subprocess actually exits.

  • Language-specific: side-by-side in the same session,

@playwright/mcp@latest (Node) survives the same ESC gesture cleanly. Only
Python dies.

  • Transport is the axis that matters: claude.ai Gmail/Calendar (remote

HTTP/SSE) unaffected by architecture. Any stdio Python MCP affected.

Please bump priority and reopen — blocks any Python MCP with multi-second tool
calls (mesh coordinators, wait loops, long queries, data pipelines).
Workaround is pinning to 2.1.104, which isn't viable for users who want
model updates.

Happy to pair-debug with an Anthropic engineer. Repro ready, bisection data
documented.

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: MCP server connection issues

Browse all Claude Code issue topics →