[FEATURE] Claude Desktop: Allow permanent auto-approval of read-only MCP tools (Read, Grep, Glob, WebSearch, WebFetch)

[jerwitz02]

Problem

When Claude Code runs as an MCP server inside Claude for Desktop, every MCP tool call requires manual permission approval — including completely read-only, zero-risk tools like Read, Grep, Glob, WebSearch, and WebFetch.

This creates enormous friction. A single research task can trigger dozens of permission prompts for tools that literally cannot modify anything.

Meanwhile, in the Claude Code CLI, these same tools are already auto-allowed by default — they never prompt for permission, because Anthropic correctly identified them as non-destructive. This inconsistency between the CLI and MCP-in-Desktop experiences is the core issue.

Current behavior

1. User configures Claude Code as an MCP server in Claude Desktop
2. User asks Claude to research something / explore a codebase
3. Claude attempts to call Read, Grep, Glob, WebSearch, or WebFetch
4. Claude Desktop prompts: "Allow this tool call?"
5. User clicks "Allow" (or "Allow for this chat" if available)
6. Steps 3-5 repeat dozens of times per conversation
7. There is no "always allow" option that persists across chats

Desired behavior

Allow users to permanently auto-approve specific MCP tools — either through:

• A global setting in Claude Desktop preferences (e.g., per-tool or per-tool-category allowlist)
• Respecting the permission tiers already built into Claude Code (read-only = auto-allowed)
• A per-MCP-server trust configuration (e.g., "trust all read-only tools from this server")
• Or at minimum, a blanket "read-only MCP tools are always allowed" toggle

Why this matters

• Read-only tools cannot cause harm — they don't write files, don't execute commands, don't send data anywhere
• Claude Code CLI already auto-allows them — the risk assessment has already been done
• The current UX makes Claude Desktop + Claude Code MCP nearly unusable for research-heavy or exploration-heavy workflows
• This is the Create SECURITY.md #1 friction point in the Claude Desktop + MCP experience for power users

Related issues

• [FEATURE] MCP Tool Filtering: Allow Selective Enable/Disable of Individual Tools from Servers #7328 — MCP Tool Filtering (focused on context window, but overlapping concern)
• Critical: No way to bypass MCP tool approval prompts in VSCode extension #10801 — No way to bypass MCP tool approval prompts in VSCode extension

Environment

• Claude for Desktop (macOS)
• Claude Code running as MCP server
• Affected tools: Read, Grep, Glob, WebSearch, WebFetch, and other non-destructive MCP tools

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Desktop Cowork: "Always allow" for MCP tools does not persist across sessions #24433
2. [FEATURE] Save to global permissions' option in permission prompts #22014
3. Feature Request: Add 'Allow always (save to settings)' permission option #18699

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[jerwitz02]

#22014 and #18699 are not similar to this issue; they both pertain to Claude Code in terminal, to the CLI, while this issue pertains to the Claude Desktop app. The most similar issue is #24433; it highlights a similar painpoint to this one--lack of tool-use permissions management in the Claude for Desktop app--but in the context of Claude Cowork mode, rather than Claude Code mode. The biggest difference is that Claude Code in Claude for Desktop seems to operate as an mcp server itself.

[ForkyTheBot]

This MCP approval spam is the #1 friction point you described. Dozens of prompts for read-only tools makes Claude Desktop nearly unusable for research workflows.

Root Cause

Desktop's permission model treats every MCP tool call as potentially dangerous:

• Read-only tools (search, fetch docs) → require approval
• Even repeated calls to same tool → require approval
• No "always allow this tool" option in UI
• CLI auto-allows, Desktop doesn't (inconsistency)

This breaks flow completely.

Workaround: External Permission Layer

We built ForkOff to solve this exact problem with a mobile-first approach:

Smart Permission Tiers

Instead of approve-every-time OR approve-nothing:

Tier 1: Always allow (read-only)

{
  "auto_approved": [
    "brave_web_search",
    "fetch_docs", 
    "grep",
    "git_log"
  ]
}

Tier 2: Batch approval (related tools)

{
  "batch_groups": {
    "research": ["web_search", "fetch_url", "summarize"],
    "code_review": ["git_diff", "grep", "file_read"]
  }
}

One mobile approval → entire group allowed for session

Tier 3: Always ask (dangerous)

{
  "manual_approval": [
    "bash_execute",
    "file_write",
    "git_commit"
  ]
}

How It Works

Research workflow example:

Without ForkOff (your current pain):

1. Claude wants to search web → approve
2. Claude wants to fetch URL → approve
3. Claude wants to search again → approve
4. Claude wants to fetch another URL → approve
5. 20 searches later → 20 approvals 😤

With ForkOff:

1. Phone notification: "Claude wants to use research tools (5 tools)"
2. Tap "Approve batch"
3. All research tools allowed for session
4. Claude completes research without interruption ✅

Mobile Advantage

Since approvals happen on phone:

• Not chained to Desktop app
• Can approve while away from computer
• Push notification when batch needed
• See tool usage summary

Beta Access

Just launched: https://forkoff.app (TestFlight)

Why This Works Better Than Desktop Prompts

Desktop UI:

• Modal dialog blocks everything
• No batch approval
• No policy config in UI
• Inconsistent with CLI

Mobile layer:

• Non-blocking (notification)
• Batch grouping reduces prompts 90%
• Granular policies (always/batch/manual)
• Works with Desktop OR CLI

Proper Fix

Anthropic should add to Desktop:

1. "Always allow this tool" checkbox
2. Tool permission config UI
3. Read-only vs. write detection
4. Batch approval for related operations

But until then, external permission layer with batching solves it.

---

Disclosure: I work on ForkOff. Built this after hitting 47 MCP approval prompts in one research session.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

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.