claude-code - 💡(How to fix) Fix claude -r freezes indefinitely when project .mcp.json has any MCP server [2 comments, 2 participants]

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

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

2. claude in that project. Let MCP init complete. Interact normally. Exit cleanly.
3. claude -r.
4. 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.