Claude for Chrome: site-level permissions unavailable for some domains, with no way to grant them

Claude for Chrome: site-level permissions unavailable for some domains, with no way to grant them

Summary

While attempting to drive a multi-step web form on dev.vk.com through the mcp__claude-in-chrome__* tools, the permission flow made the feature unusable. Seven distinct problems compounded: a permanent site-level grant was impossible for the target domain and the UI offered no way to create one; the per-action prompt rendered in a browser window the user was not looking at and silently resolved to "denied"; each denial destroyed the MCP tab group and all in-page progress; and batching was unavailable precisely on the sites that need it most.

The session was abandoned after roughly 30 minutes spent entirely on permission plumbing. The actual task — creating and configuring a VK Mini App — never started. The user fell back to the Claude desktop app's in-app browser, which required logging in to the site again from scratch.

Environment

• macOS (Darwin 27.0.0)
• Google Chrome with the "Claude for Chrome" extension
• Claude Code CLI; the session was later continued in the Claude desktop app (Code tab)
• Target site: dev.vk.com (VK developer cabinet); the user was already logged in in their real Chrome profile
• Date: 2026-09-16

Problem 1 — Site-level permissions are silently unavailable for a site, with no way to enable them

The extension's permission dialog reads:

Claude wants to read page content on: dev.vk.com

It offers exactly two options: Allow this action and Decline. The dialog's own footer states:

Site-level permissions are disabled for this site.

There is no way to act on that statement:

• The extension settings page ("Claude in Chrome settings" → Permissions → "Your approved sites") is a read-only list with a Revoke action per site. There is no "add site" affordance.
• A site can therefore only ever reach that list via the permission dialog — but for this domain the dialog never offers the permanent option.

Result: a permanent grant is impossible for this domain, and the dialog reappears for essentially every action. The UI gives no explanation of why site-level permissions are disabled for this particular site, and offers no path to change it.

Requested changes

1. Surface the reason directly in the dialog (why is this site excluded?).
2. Provide an "add site" control in the extension settings, so a domain can be approved without waiting for a dialog that never offers the option.
3. If a domain is deliberately excluded from permanent grants, say so explicitly and name the policy that excludes it.

Problem 2 — The permission prompt renders in a window the user is not looking at, and silently times out as "denied"

The prompt appears in a separate "Claude for Chrome" browser window, while the user is watching the terminal (or the desktop app). When the prompt is left unattended, the action resolves as:

Permission denied by user

The tool result is indistinguishable from a deliberate denial. During this session the user repeatedly reported "I allowed everything" while the tool kept reporting that the user had denied the action — there was no way, from the tool result alone, to tell a timeout apart from a real decline, and therefore no way to diagnose what was actually happening.

Requested changes

1. Distinguish timeout from explicit denial in the tool result (distinct error text or an explicit reason field).
2. Mirror the prompt into the client that initiated the action (CLI / desktop app), or at minimum raise a visible notification there.

Problem 3 — A denial destroys the MCP tab group and all in-page progress

After each denied action, tabs_context_mcp returned a brand-new empty tab (chrome://newtab/) under a new tabGroupId. This was observed at least four times in the session, with different ids each time:

1135988029 → 2127318064 → 1876057958 → 1131817572

The partially filled form (the app name had already been typed into the field) was lost every time, forcing a restart of the whole flow. Combined with Problem 2 — where prompts time out as denials without the user ever seeing them — this makes forward progress on any multi-step form effectively impossible.

Requested change

A denied action should fail that action only. It must not tear down the session's tab group or discard the tabs under automation.

Problem 4 — browser_batch cannot surface a permission prompt, making batching useless on such sites

Calling a batch on the target site fails with:

permission_required: dev.vk.com — call computer standalone (not in browser_batch) so the user is prompted

This is self-defeating. Batching exists to reduce round-trips, but on any site that needs a prompt you are forced back to one action per call — which maximizes the number of prompts the user has to answer, on exactly the sites where prompts are most frequent.

Requested change

Allow the permission prompt to be raised from inside a batch, and resume the remaining actions in the batch once the user approves.

Problem 5 — The extension's own permission window steals focus and breaks typing

With the "Claude for Chrome" window in front, computer{action:"type"} failed with:

Failed to type: Cannot access a chrome-extension:// URL of different extension

A click on the target element (ref_16) had succeeded immediately before, so the tool clearly had the correct page. Only typing failed — the typing path targeted the extension's own page rather than the page it had just clicked into.

Requested change

The automation target should stay pinned to the tab under automation, regardless of which window currently has OS focus. Input injection must not follow the frontmost window.

Problem 6 — bypassPermissions mode is not discoverable, and does not cover extension prompts

• Shift+Tab cycles only through normal → auto-accept edits → plan mode. bypass permissions does not appear in the cycle unless the CLI was launched with --dangerously-skip-permissions. This is worth documenting in the mode indicator itself, so users are not left hunting for a mode that cannot be reached from the keyboard.
• Even once bypass mode was active, the extension's site-level prompts still fired. The two permission systems being independent is defensible, but nothing in the UI explains it, so the user reasonably expects bypass mode to cover browser actions and is left confused when it does not.

Requested changes

1. Indicate in the mode indicator that bypass mode requires the launch flag.
2. State explicitly — in the mode indicator or in the extension prompt — that the Claude Code permission mode does not govern extension site permissions.

Problem 7 — No path forward from the agent side either

The agent could not add its own permission rules. Both writing .claude/settings.local.json and invoking the update-config skill were blocked by the auto-mode classifier with reason [Self-Modification].

That block is correct behavior on its own. But combined with Problems 1 and 2 it leaves no path forward from either direction: the agent cannot grant the permission, and the user cannot grant it permanently. The session simply dead-ends.

Reproduction

1. In Chrome with the "Claude for Chrome" extension, log in to a site for which site-level permissions are disabled (observed on dev.vk.com).
2. From Claude Code, use mcp__claude-in-chrome__* tools to interact with a multi-step form on that site.
3. Observe the permission dialog: only "Allow this action" / "Decline", with the footer "Site-level permissions are disabled for this site."
4. Open the extension settings → Permissions → "Your approved sites" and observe there is no way to add a site.
5. Leave the prompt unattended (as happens naturally while watching the terminal) and observe the tool result Permission denied by user.
6. Call tabs_context_mcp and observe a new empty tab with a new tabGroupId; all in-page progress is gone.
7. Attempt the same actions via browser_batch and observe permission_required: ... call computer standalone.

Impact

Roughly 30 minutes of a real work session were spent entirely on permission plumbing. The intended task never started. The Chrome path was abandoned in favor of the desktop app's in-app browser, which required re-authenticating with the target site from scratch, discarding the value of driving the user's already-logged-in Chrome profile in the first place.

Problems 1–4 in combination make the extension unusable for any multi-step web task on an affected domain: the grant cannot be made permanent, the prompt is easy to miss, missing it reads as a denial, and a denial wipes out the work done so far.