[BUG] MCP tool call hangs silently with no prompt rendered (local OR remote) and no tool_result ever returned

Summary

A Claude Code session emitted a tool_use block for a non-allowlisted MCP tool (memory_write on a custom HTTP MCP server), then hung for 42+ minutes with zero telemetry:

• No permission prompt rendered in the local TUI
• No permission prompt rendered in the claude.ai/code remote-control UI
• No tool_result ever returned
• Session JSONL log contains no events at all during the 42-minute gap
• MCP backend logs show zero HTTP requests from this client during the gap — the call never left Claude Code

Recovery required pressing Esc in the local TUI (no choice was rendered to answer).

This is observably distinct from #60385 (filed earlier today). In #60385 the prompt at least renders in the local TUI, the user can answer it, and a tool_result eventually surfaces. Here, nothing happens.

Environment

• Claude Code version: 2.1.143
• Launch: claude --remote-control wedding (wrapped in screen -DmS claude-wedding under a systemd user unit)
• Host: Linux x86_64, Ubuntu 24.04, kernel 6.17.0
• Remote UI: claude.ai/code/ (web)
• MCP server: custom HTTP MCP at 127.0.0.1:8081, proxied through Apache (TLS), healthy throughout (zero errors in its logs)
• Tool: mcp__claude_ai_MemoryManagement__memory_write — NOT in .claude/settings.local.json permissions.allow at the time, so a permission check was expected
• Other allowlisted MCP tools (memory_read_all, Faure_ca_MCP__run_command, etc.) worked fine in the same session before and after the hang

Timeline (UTC, from session JSONL)

\\\
23:47:46 tool_use ToolSearch (resolved memory_write schema in <1s)
23:48:04 tool_use mcp__claude_ai_MemoryManagement__memory_write
— service_id=\"PHwedding\", key=\"current_state/save-the-date-site\"
— value ~1.9 KB
[ 23:48:04 → 00:30:32 no entries in session JSONL — 42-minute silent gap ]
~00:25 external \screen -X stuff \$'\e'\ sent Esc into the local TUI
00:30:32 user message: \"How are we doing?\"
00:31:03 tool_use mcp__claude_ai_MemoryManagement__memory_write (retry, now allowlisted)
00:31:05 tool_result success (version=2, took ~2 seconds end-to-end)
\\\

What I checked during the hang

1. Local TUI scrollback (\screen -X hardcopy -h\, 1086 lines): zero matches for \"proceed\", \"Allow\", \"permission\", \"denied\". No permission dialog rendered anywhere — visible or scrolled-off.
2. Web UI (claude.ai/code): showed only \Writing memory updates… (1h 1m 30s · ↓ 74.2k tokens)\ spinner. No prompt, no error.
3. MCP backend logs (\mcp-memory.service\): zero requests from this client between \23:48:04\ and the successful retry at \00:31:03\. The request never left Claude Code.
4. Session JSONL (\~/.claude/projects/<encoded>/<session-id>.jsonl\): the 42-minute gap contains no events at all — no permission_request, no tool_result, no error.

Comparison with #60385

| | #60385 | This issue |
|---|---|---|
| Prompt rendered in local TUI | ✅ yes | ❌ no |
| Prompt rendered in remote UI | ❌ no | ❌ no |
| \tool_result\ eventually surfaced | ✅ as \Tool result missing due to internal error\ | ❌ never |
| Session log entries during hang | present | empty |
| Recovery | answer prompt on local TUI | \Esc\ only — no choice rendered |

May share a root cause but are observably different.

Reproduction

I don't have a reliable, minimal repro. Conditions that were present:

• Custom HTTP MCP server (not stdio MCP)
• Tool requiring permission check (not in allowlist)
• Non-trivial value payload (~1.9 KB)
• Session ~27 minutes old, mid-task with several preceding successful tool calls
• Remote-control client connected, but tool dispatch should be a local concern

I'd like to know whether this correlates with payload size, MCP transport (stdio vs HTTP), session length, or compaction state. Happy to instrument my next session aggressively.

Workaround

Pre-allowlist the specific MCP tool in \.claude/settings.local.json\ under \permissions.allow\. The retry after allowlisting succeeded in 2 seconds — implying the MCP layer itself is fine; only the permission-check path is broken.

Notes

• Full session JSONL is available on request — I'd prefer to share privately rather than paste publicly (contains project content). Happy to send via \/feedback\ or another channel.
• Related: #60385 (filed earlier today, same date) — different observable failure mode in the same general area.