[FEATURE] Allowlist-only file access + deny rules for MCP tools (WebFetch, WebSearch)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Summary

Two related gaps in the current permissions system expose users to unintended
data access and exfiltration risks:

1. No allowlist-only file access mode
2. deny rules do not cover built-in MCP tools (WebFetch, WebSearch)

---

Request 1 — Allowlist-only file access mode

Currently deny always takes precedence over allow. There is no way to say
"only allow access to this folder and block everything else by default."

Requested behaviour

Add a defaultDeny mode where file access is blocked everywhere unless
explicitly allowed:
{
"permissions": {
"defaultDeny": true,
"allow": [
"Read(D:\\Projects\\myapp\\)",
"Write(D:\\Projects\\myapp\\)",
"Edit(D:\\Projects\\myapp\\**)"
]
}
}

Why this matters

The current deny-list approach requires users to anticipate and enumerate every
sensitive location on their machine. An allowlist model inverts this: only the
project folder is accessible, everything else is protected automatically.

Current workaround

Manually deny individual sensitive paths in user-level settings.json.
This is fragile — any path not explicitly listed remains accessible.
---

Request 2 — deny rules for MCP tools (WebFetch, WebSearch)

Currently deny rules only match Bash and PowerShell commands. Built-in MCP tools
like WebFetch and WebSearch are not covered.

The risk

WebFetch is an outbound HTTP channel. If Claude reads a sensitive file, it could
theoretically send that content to an external URL via WebFetch. There is currently
no way to hard-block this in settings.json.
WebSearch sends queries to an external search engine — those queries could contain
sensitive data extracted from local files.

Requested behaviour

Allow deny rules to match MCP tool calls by name:
{
"permissions": {
"deny": [
"WebFetch(*)",
"WebSearch(*)"
]
}
}
This would give users the same hard-block guarantee for internet access that
Bash deny rules provide for shell commands.

Current workaround

Users can only decline the permission prompt at runtime — there is no
pre-configured block. The prompt can be missed or misunderstood.
---

Why these matter together

A user who locks down their file system with deny rules still has an open
outbound channel through WebFetch. Both gaps need to be closed for the
permissions system to provide meaningful security guarantees.

Platform

Windows 11, Claude Code CLI

Proposed Solution

Implement the Allow deny rules to match MCP tool calls by name:
{
"permissions": {
"deny": [
"WebFetch(*)",
"WebSearch(*)"
]
}
}

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_