Claude-in-Chrome prompts on every browser action — settings.json allow rules, all permission modes, extension approved-sites, AND CLAUDE_CHROME_PERMISSION_MODE all fail (v2.1.220 / ext 1.0.84)

Summary

Claude-in-Chrome prompts for permission on every single browser action (computer, navigate, read_page, find, form_input, tabs_context_mcp). One session logged 813 messages in 90 minutes looping computer → find → form_input, with a dialog on each call.

This is related to #74715 / #67020 / #66125, but adds new information: every documented workaround, including the ones those issues call verified, fails.

Environment

| | |
|---|---|
| Claude Code | 2.1.220 |
| Claude Chrome extension | 1.0.84 |
| Chrome | 151.0.7922.75 |
| macOS | 26.6 (25G72), Apple Silicon |
| Surface | Claude desktop app (bundled claude-code) |

Workarounds tried — all fail

1. permissions.allow rules — 193 rules in ~/.claude/settings.json covering server-level (mcp__claude-in-chrome), wildcard (mcp__claude-in-chrome__*), and every fully-qualified tool name, across 5 historical server-name spellings. Also present in project .claude/settings.local.json. No effect.
2. All permission modes — default, acceptEdits, and bypassPermissions all prompt identically.
3. Extension side-panel mode — set to "Skip all approvals" (skip_all_permission_checks). No effect.
4. Extension Settings → Permissions → approved sites — added the affected domains via the supported UI per the official permissions guide. No effect.
5. CLAUDE_CHROME_PERMISSION_MODE=skip_all_permission_checks — set in settings.json env and ~/.zshrc. Verified live via printenv inside the Claude process. App fully restarted. No effect. ← this is the main new data point
6. Direct permissionStorage write (LevelDB, Chrome closed) — records written with duration:"always", single-JSON-encoded, verified readable. No effect.
7. macOS Full Disk Access on every claude binary — unrelated, no effect.

Confirming the settings layer IS parsed

A deny rule in the same settings.json works correctly:

"deny": ["Read(//Users/<me>/.ssh/**)"]

→ returns "File is in a directory that is denied by your permission settings."

So permissions is parsed and enforced — but allow rules never reach the Chrome tool path, while deny rules elsewhere do.

Observed detail

Prompts fire even for tools with no URL argument at all, e.g.:

{ "tool": "tabs_context_mcp", "args": { "createIfEmpty": false } }

Reading mcpPermissions-*.js in the extension, findApplicablePermission only matches scope.type === "netloc" and requires t.scope.netloc to be truthy. A tool call with no URL therefore cannot match any stored grant, and an empty-hostname scope (what file:// URLs produce) is filtered out by the truthiness check. matchesNetloc supports *.domain wildcards, but normalization strips a trailing dot, so a bare *. cannot act as a catch-all.

Expected

Either permissions.allow rules, the extension's approved-sites list, or CLAUDE_CHROME_PERMISSION_MODE should suppress per-action browser prompts.

Actual

None of them do. Every browser action prompts, indefinitely, making agentic browser work unusable.

Repro

1. Add mcp__claude-in-chrome__computer to permissions.allow in ~/.claude/settings.json.
2. Set CLAUDE_CHROME_PERMISSION_MODE=skip_all_permission_checks; restart the app.
3. In the extension, set mode to "Skip all approvals" and add the target site under Settings → Permissions.
4. Ask Claude to perform any multi-step browser task.
5. A permission dialog appears on every action.