Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Remote Control: MCP permission prompts for non-read tools never surface in claude.ai/code web UI

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When using --remote-control to drive Claude Code from the claude.ai/code web UI, permission approval prompts for some MCP tool calls never render in the web UI. They appear only in the local TUI (screen session on the host), where they block the session until manually answered via SSH.

This is broader than a single MCP server — observed against both a bundled claude.ai connector and a custom user-built MCP server.

Error Message

  • The web UI shows the tool call as in flight, then reports Tool result missing due to internal error; the conversation appears hung. No indication that approval is needed.

Root Cause

When using --remote-control to drive Claude Code from the claude.ai/code web UI, permission approval prompts for some MCP tool calls never render in the web UI. They appear only in the local TUI (screen session on the host), where they block the session until manually answered via SSH.

This is broader than a single MCP server — observed against both a bundled claude.ai connector and a custom user-built MCP server.

Fix Action

Workaround

Pre-allowlist the specific MCP tool names in .claude/settings.local.json:

```json { "permissions": { "allow": [ "mcp__<server-id>__<tool-name>" ] } } ```

This eliminates the prompt entirely, sidestepping the bug — but requires knowing each tool's MCP name in advance and defeats per-call control.

Code Example

Do you want to proceed?
    1. Yes
    2. Yes, don't ask again for X in this session
    3. No
RAW_BUFFERClick to expand / collapse

Summary

When using --remote-control to drive Claude Code from the claude.ai/code web UI, permission approval prompts for some MCP tool calls never render in the web UI. They appear only in the local TUI (screen session on the host), where they block the session until manually answered via SSH.

This is broader than a single MCP server — observed against both a bundled claude.ai connector and a custom user-built MCP server.

Environment

  • Claude Code version: 2.1.143
  • Launch: claude --remote-control <session-name> (interactive, wrapped in screen -DmS claude-<name> under a systemd user unit)
  • Host: Linux x86_64, Ubuntu 24.04, kernel 6.17.0
  • Remote UI: claude.ai/code/ (web)
  • No --dangerously-skip-permissions, no permissionMode: bypassPermissions

Steps to Reproduce

  1. Configure two MCP servers — one bundled claude.ai connector (e.g. a file-server), one custom user MCP. Do NOT pre-allowlist their write/delete tools in settings.local.json.
  2. Launch claude --remote-control session-1 on the host (inside a screen session under a systemd user unit).
  3. Connect to the same session from claude.ai/code's web UI.
  4. From the web UI, ask Claude to call either:
    • claude.ai MCP write_file to an allowed path, or
    • Custom MCP memory_write / memory_delete (or any write/destructive tool)
  5. Observe the web UI vs. what's actually on the host.

Expected

A permission approval prompt renders in the claude.ai/code web UI. User clicks Allow / Allow Once / Deny.

Actual

  • The web UI shows the tool call as in flight, then reports Tool result missing due to internal error; the conversation appears hung. No indication that approval is needed.
  • The actual prompt is sitting in the local TUI in the screen session: 
    Do you want to proceed?
  1. Yes
  2. Yes, don't ask again for X in this session
  3. No
  • The session stays blocked until someone SSHes in, screen -rs, and answers manually. Prompts have sat 50+ minutes this way.

Affected vs. Unaffected Tools

In the same session, with the same MCP servers, prompts for some tools surface fine while others do not:

ToolWeb-UI prompt surfaces?
MCP run_command (read-only)✅
MCP read_file✅
claude.ai MCP write_file❌
Custom MCP memory_write, memory_delete❌

Pattern looks category-based (write/destructive ops?), not a per-server bug. Not Agent Teams / --teammate-mode — this is a vanilla single-session --remote-control.

Possibly Related

  • #48549 (closed) — same symptom in Agent Teams via Remote Control. The teammate-specific fix may not cover single-session --remote-control.
  • #46392 (open) — tmux teammate mode, similar symptom but different code path.

Workaround

Pre-allowlist the specific MCP tool names in .claude/settings.local.json:

```json { "permissions": { "allow": [ "mcp__<server-id>__<tool-name>" ] } } ```

This eliminates the prompt entirely, sidestepping the bug — but requires knowing each tool's MCP name in advance and defeats per-call control.

Notes

  • I do not believe this is server-side. The MCP spec puts permission UI entirely on the client; server tools shouldn't need to do anything special.
  • First noticed locally on 2026-05-14 with write_file; reconfirmed 2026-05-19 with a custom memory-management MCP server. Bug is stable across multiple sessions and Claude Code versions in the 2.1.x line.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#memory management#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING