claude -r freezes indefinitely when project .mcp.json has any MCP server

Resolved 💬 3 comments Opened Apr 24, 2026 by dowglaz Closed Apr 24, 2026

Environment

  • Claude Code 2.1.119
  • macOS 26.4.1 (Darwin 25.4.0, arm64)
  • Reproduced on a colleague's machine (different hardware, same symptom)

Summary

Resuming a session (claude -r) in a project whose .mcp.json has any MCP server configured leaves the TUI frozen — the assistant never responds to new input. /mcp doesn't return either. Starting a fresh (non--r) session in the same project works fine.

Behavior appears independent of which MCP server is configured. Tested with memory, mcp-atlassian, and taylorwilsdon/google_workspace_mcp; each, on its own, is sufficient to reproduce. Starting from an empty .mcp.json and adding one at a time shows each addition surfaces the same failure mode on the next -r.

Reproduction

  1. In a project, create .mcp.json with a single server, e.g.:

``json
{ "mcpServers": { "atlassian": { "command": "uvx", "args": ["mcp-atlassian"] } } }
``

  1. claude in that project. Let MCP init complete. Interact normally. Exit cleanly.
  2. claude -r.
  3. TUI appears, last exchange is shown, new prompts are accepted but never processed.

Expected

Resume completes, assistant responds to new input, /mcp returns the server list.

Actual

Session is frozen — no assistant output, no /mcp response. Kill + fresh claude works; fresh sessions with the same .mcp.json are unaffected.

Evidence

Session jsonl tail from a frozen resume (post-resume markers present, no further events):

... 2:05:26Z  user       tool_result
... 2:05:30Z  assistant  text          <-- last pre-exit message
          -   last-prompt
          -   permission-mode
          -   permission-mode           <-- resume happens, then nothing

Happy to share the full jsonl privately if useful.

Workaround

Start fresh sessions (no -r) when any MCP server is configured.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗