[BUG] Built-in browser: the per-site permission card has no working persistent grant, and in third-party deployments it cannot be skipped at all

Summary

The built-in browser's per-site permission card has no working persistent grant. Seventeen separate reports over the last month describe the same underlying behaviour from different angles: a site is on the allow list, or "Allow all websites" is set, or the session runs in bypass-permissions mode, and the card appears anyway, on every navigation and often on every action.

This issue collects them so the pattern is visible in one place, and adds one finding I have not seen reported: in a third-party deployment the card can never be skipped, whatever the user sets, because the skip is gated on a claude.ai account check that a third-party build answers with a hard false.

The reports, grouped

The allow list is not honoured by the built-in browser

• #91495 (10 comments, open since 2 September) "Allow all websites" ignored, permission dialog on every tool call. Re-tested on 2.7032.0 on 22 September and still present.
• #86384 (closed) a site on the Allowed sites list still raises a card.
• #93655 the per-action origin prompt has no "Allow always" option and ignores the settings.
• #93201 and #94830 the same for internal and .local hostnames.

"Always allow" is accepted and then not persisted

• #74715 (19 comments) the grant is stored with duration: "once".
• #67020 not honoured, re-prompts on every action.
• #82835 and #93328 never persisted across scheduled task runs.
• #90078 no persistent grant for screenshot actions, unlike navigation.

Bypass and auto mode do not reach the browser layer

• #84514 per-site approval cards ignore bypass-permissions mode, with a request for a way to opt out.
• #96096 (22 September) every Chrome tool call prompts in bypass mode on 2.1.280, "Always allow" has no lasting effect.
• #84390 the auto mode classifier blocks tool calls while the session is in bypassPermissions.

Private network hosts

• #90305 a persistent grant exists for reading but not for interaction, so every click and scroll raises its own card.
• #77236 (closed) no exemption for local or private-network origins on the JavaScript execution gate.

The finding that is not yet in any of them

In a third-party deployment (deploymentMode: 3p, an inference gateway rather than a claude.ai account) the card is unconditional.

Reading the shipped bundle of 2.7032.0, the function that decides whether to skip the card returns early unless authenticatesHostedSiteCheck() is true, and only then looks at the session's permission mode:

function Zpn(e){ if(!Ypn||!e||!mpn()) return !1; let t=Ypn(e); return t==="auto"||t==="bypassPermissions" }
function mpn(){ return W().authenticatesHostedSiteCheck() }

The bundle carries two implementations of that method, return !0 for the claude.ai deployment class and return !1 for the third-party one. So on a third-party deployment the permission mode is never consulted and every new origin raises a card, no matter what the user sets. The per-origin allow list (preferences.launchPreviewAllowedOrigins) is the only thing that avoids it, one exact origin at a time, and a * entry is rejected by the validator with a message pointing at builtinBrowserDefaultDomainPolicy, which governs which sites may be opened rather than whether the card appears.

The same build also gates the 1Password credential tools on shouldEnableChromeExtensionBridge(), which for a third-party deployment depends on claudeInChromeEnabled. That key is documented in the app itself as set only by the claude.ai control plane, with "a value stored anywhere else is ignored", so a third-party deployment cannot turn on the integration that would otherwise fill these forms.

Environment

• macOS 26.3, Apple silicon
• Claude desktop app 2.7032.0, third-party deployment mode against an LLM gateway
• Claude Code 2.1.280 bundled by the app
• Reproduced on 2.2553.1 before the update, and by other reporters on 1.37937.1

Reproduction

1. Run the desktop app in third-party mode with the built-in browser enabled.
2. Start a Code session in bypass-permissions mode.
3. Ask Claude to open any site that is not already in Allowed sites.
4. The card "Allow Claude to act on <site>?" appears. It appears again for the next new site, and for every subsequent one.

The app records each one in its log, which is a convenient way to count them:

[PreviewOriginPolicy] origin prompt: in-app card for serverId=preview-local_…
[PreviewOriginPolicy] origin prompt (card) decision: allow_always

What would fix it

1. Make the Allowed sites list authoritative for the built-in browser, and persist "Always allow" as a durable grant rather than duration: "once". That closes most of the reports above.
2. Consult the session's permission mode in third-party deployments too. The account check gates a user-visible behaviour on a deployment detail that the user cannot change.
3. Give the allow list a wildcard, or honour builtinBrowserDefaultDomainPolicy: allow for the action card as well as for navigation, so an operator can express "this machine trusts every site" once rather than per origin.

Happy to test a build on any of these.