Claude Browser (in-app browser) cannot be reliably disabled, undermining self-imposed distraction blockers

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

I use Cold Turkey Blocker to manage distraction by blocking specific websites and apps at the OS level. I discovered that the Claude Desktop app's "Browser pane" (in-app browser, the mcp__Claude_Browser__* tool family) completely bypasses this — and after investigating with Claude's help, we could not find any way to close the gap without disabling the whole app.

**What we tried, and what we found**
1. permissions.deny in ~/.claude/settings.json Added a deny rule for all mcp__Claude_Browser__* tools (navigate, computer, browser_batch, find, form_input, get_page_text, javascript_tool, preview_start/stop/list/logs, read_console_messages, read_network_requests, read_page, resize_window, tabs_*) at the user-level settings file. Verified the JSON was valid and correctly parsed.

Result: no effect. After a full session restart, and after a full computer restart, the Browser pane in the Claude Desktop app was still fully usable. The deny rule appears to only gate Claude's own tool calls, not the user's direct interaction with the Browser pane through the app's UI — and even that is unconfirmed, since it never visibly blocked anything.

2. Windows Firewall / process-level blocking Investigated whether the Browser pane could be isolated as a separate OS process so it could be blocked without blocking the whole app.

Found that Claude Desktop is an Electron app. Every process (main, gpu-process, crashpad-handler, utility, renderer) runs from the same executable: ...\Claude_\app\Claude.exe. Windows Firewall rules filter by executable path, not by Electron's internal --type= process role, so a firewall rule can only block the entire app, not the embedded browser specifically.

Inspected live TCP connections while the Browser pane was open. Found multiple concurrent "main"-type processes connecting to different cloud IP addresses (at least one likely Anthropic-owned, others resolving to Google Cloud IP ranges with no PTR/reverse-DNS records). Traffic was not cleanly separable into "browser pane" vs. "everything else" — no isolated endpoint could be identified to target with a scoped firewall rule.

3. Contacted Cold Turkey support directly They confirmed: "there's no way to block embeds or supported browsers launched with custom profiles with my app" and suggested hosts-file edits or Windows Firewall rules as workarounds — both of which assume the embedded browser is a separately identifiable local process or makes direct outbound connections distinguishable from the host app. Per point 2 above, that assumption doesn't hold for Claude Desktop's Electron architecture, so neither workaround is actually usable here.

Why this matters
Someone who deliberately sets up tools like Cold Turkey to block distracting/addictive sites has no reliable way to also restrict Claude's in-app Browser pane not through Claude's own settings (which don't appear to gate it), and not through OS-level tools (because the app's process architecture makes selective blocking technically infeasible). The one documented lever (permissions.deny) silently does nothing for this feature in the Desktop app, which is arguably worse than no lever at all, since it gives false confidence that the restriction is in place.

What we'd like to see
A setting that actually works. Either make permissions.deny for Browser-pane tools effective in the Desktop app, or add a dedicated toggle (e.g., in-app Settings → Tools/Connectors → Browser) that fully disables the Browser pane, verified to hold across sessions and restarts.
A "Focus/Restricted mode" that structurally disables high-risk capabilities (Browser, WebFetch, WebSearch) at the app level, ideally requiring a deliberate multi-step action to re-enable (mirroring how self-control tools like Cold Turkey's own lock code work), rather than a config file that can be silently ignored or trivially edited back.
Documentation transparency on whether Browser pane traffic is proxied through Anthropic-controlled infrastructure or originates directly from the local machine — this determines whether OS-level blocking (hosts file, firewall) can ever work, and users deserve to know instead of guessing.
If a native toggle isn't feasible short-term: expose the Browser pane's process as a separately identifiable executable/process so that third-party OS-level tools (firewalls, app blockers) can at least target it independently from the rest of the app.

Happy to provide more detail (OS: Windows 11, Claude Desktop version 1.49585.0.0) if useful.

### What Should Happen?

The Browser pane should be fully and verifiably disabled when the user configures permissions.deny for mcp__Claude_Browser__* in settings.json both for Claude's own tool calls and for direct user interaction with the pane in the Desktop app. Currently the setting has no effect on the Desktop app, even after a full restart, giving false confidence that the restriction is active.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

1. Open Claude Desktop, go to any Code tab session.
2. In `~/.claude/settings.json`, add:
```json
{
"permissions": {
"deny": [
"mcp__Claude_Browser__navigate",
"mcp__Claude_Browser__computer",
"mcp__Claude_Browser__browser_batch",
"mcp__Claude_Browser__find",
"mcp__Claude_Browser__form_input",
"mcp__Claude_Browser__get_page_text",
"mcp__Claude_Browser__javascript_tool",
"mcp__Claude_Browser__preview_list",
"mcp__Claude_Browser__preview_logs",
"mcp__Claude_Browser__preview_start",
"mcp__Claude_Browser__preview_stop",
"mcp__Claude_Browser__read_console_messages",
"mcp__Claude_Browser__read_network_requests",
"mcp__Claude_Browser__read_page",
"mcp__Claude_Browser__resize_window",
"mcp__Claude_Browser__tabs_close",
"mcp__Claude_Browser__tabs_context",
"mcp__Claude_Browser__tabs_create",
"mcp__Claude_Browser__tabs_select"
]
}
}
```
3. Save the file.
4. Fully quit Claude Desktop (not just close the window) and restart the machine to rule out caching.
5. Open Claude Desktop again, start a new session.
6. Open the Browser pane manually from the UI (or ask Claude to open a URL).

**Expected:** the Browser pane is blocked/unavailable, matching the deny rule.
**Actual:** the Browser pane opens and functions normally — the deny rule has no observable effect.

### Claude Model

Other

### Is this a regression?

No, this never worked

### Last Working Version

_No response_

### Claude Code Version

1.49585.0.0

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

_No response_

Start by reproducing on Windows 11 with Claude Desktop 1.49585.0.0 using the ~/.claude/settings.json permissions.deny entries for mcp__Claude_Browser__*. Check whether the Browser pane and Claude-initiated browser tool calls share the same permission path. Done means the Browser pane is verifiably disabled across full app and machine restarts, or a dedicated documented toggle provides that behavior.

Written by the indexing model from the issue text.