Claude Browser action confirmations ignore permissions.allow and defaultMode: bypassPermissions

Summary

Claude Browser tool calls (javascript_tool, computer, browser_batch) trigger a secondary "Unknown external action. Confirm before proceeding." dialog that is completely independent of permissions.allow / permissions.defaultMode in settings.json — including for tools that are explicitly allowlisted. The dialog also doesn't differentiate by risk: a passive {"action": "screenshot"} gets identical treatment to JS that mutates the DOM (clicking buttons, hiding elements). For workflows that call the Browser tool repeatedly (e.g. iterating on a UI mockup), this trains the user to reflexively click "Allow once" on every single action, which defeats the purpose of the confirmation — a genuinely risky action would look no different from a benign one and would likely get rubber-stamped along with everything else.

Environment

• Claude Desktop app, macOS (Darwin)
• Date observed: 2026-08-28

Steps to reproduce

1. In ~/.claude/settings.json, set:

``json
"permissions": {
"allow": [
"mcp__Claude_Browser__computer",
"mcp__Claude_Browser__javascript_tool",
"mcp__Claude_Browser__*"
],
"defaultMode": "bypassPermissions"
}
``

1. Start a fresh session in the Claude Desktop app.
2. Ask Claude to take a screenshot via the Claude Browser pane (computer tool, action: "screenshot"), or to run JS via javascript_tool, or a multi-step browser_batch.

Expected behavior

No confirmation prompt — the tool is explicitly named in permissions.allow, and defaultMode is bypassPermissions.

Actual behavior

A dialog appears every time: "Allow Claude to use \<tool\> (Claude Browser)?" / "Unknown external action. Confirm before proceeding." (or "External action detected." for batches), with only Deny / Allow once — no persistent "Always allow" option. This happened for:

• javascript_tool with a DOM-mutating script (clicking a button, hiding elements)
• browser_batch combining a navigate + computer screenshot against localhost:8791
• computer with a bare {"action": "screenshot"} — despite mcp__Claude_Browser__computer being explicitly present in permissions.allow in both the global and project settings.json

Same result with permissions.defaultMode: "bypassPermissions" set globally.

Why this matters

Because the confirmation fires identically for every action regardless of actual risk (read-only screenshot vs. DOM-mutating JS), and because it can't be allowlisted like every other tool permission, it becomes pure noise in any workflow that calls the Browser tool repeatedly. The realistic outcome is reflexive clicking, not review — which means the one time the payload actually is dangerous, it's no more likely to get caught than a routine screenshot.

Suggested directions

• Honor permissions.allow / defaultMode: bypassPermissions for this confirmation the same as other tools, or
• Add a persistent "Always allow for this tool/session" choice to the dialog itself, or
• Differentiate the confirmation by actual risk (e.g. read-only actions like screenshot/read_page shouldn't require the same friction as state-changing actions)

Happy to provide more repro detail if useful.