[BUG] Built-in browser ignores Allowed sites for internal hostnames (*.habifino.local): "Site-level permissions are disabled for this site", prompt on every action

### 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?

## Summary

The built-in browser (Claude Desktop browser pane, `mcp__Claude_Browser__*` tools, used by both Cowork and Claude Code launched from the desktop app) refuses site-level permissions for our on-prem hostnames and prompts on **every acting call** (click, type, key). Reads (`navigate`, `screenshot`, `read_page`, JS reads) do not prompt; the first click does.

The prompt now says it explicitly:

> Allow Claude to access servdev.habifino.local?
> Site-level permissions are disabled for this site. You'll be asked for each action.

The hosts are in **Settings → Cowork → Allowed sites**, correctly formatted (verified in `claude_desktop_config.json`, key `preferences.launchPreviewAllowedOrigins`: `https://servdev.habifino.local`, `https://servprdap1.habifino.local`). Permission mode was tested in auto and in skip-all. `bypassPermissionsModeEnabled` is true. None of it is honoured for these hosts.

## What we isolated (three sittings: 2026-08-30, 2026-09-06, 2026-09-09)

The deciding variable is whether the hostname sits under an ICANN public suffix. Nothing else.

| Host | Reachability | Certificate | Allowlisted | Result |
|---|---|---|---|---|
| `servdev.habifino.local` (SAP dev, SAP GUI for HTML) | LAN/VPN only | AD CA, trusted on the Mac | yes | prompt on every action |
| `servprdap1.habifino.local` (SAP production) | LAN/VPN only | AD CA, trusted on the Mac | yes | prompt on every action |
| `ubuntu0.local.areastore.com` (internal Guacamole gateway) | LAN/VPN only | trusted | yes | **silent**, allowlist honoured |
| `areastore.com` (public site) | public | public CA | yes | silent |

The third row is the control: an equally internal, LAN-only host, same allowlist file, same modes, same trust. The only difference is that `areastore.com` is a registrable domain and `habifino.local` is not. Ruled out one by one: certificate validity (production has a valid trusted cert and behaves exactly like dev), permission mode, allowlist entry format, the Preferred-browser toggle, app restarts, fresh conversations.

Related: #91495 reports the same symptom against Laravel `*.test` hosts with "Allow all websites" on, and #91976 (marked duplicate) reports per-site prompting on ordinary public sites. This report is narrower: for hosts under a non-public suffix the allowlist entry itself is ignored and the prompt states that site-level permissions are disabled. Also related: #75289 (localhost cannot be allowlisted).

## Why this matters to us, stated plainly

We are a retailer running SAP ECC on-prem. Our users reach it through SAP GUI for HTML on `*.habifino.local`. The whole point of the browser tools for us is agent-driven work inside SAP: bulk material maintenance, table reads, transport handling. A run of a few hundred rows means a few hundred approval prompts, so the built-in browser is unusable for our primary use case. We currently fall back to Claude in Chrome for SAP.

We are not going to rename our internal infrastructure to sit under a public domain in order to route around this rule. We found that it would work, and we are telling you so here instead of doing it. We want the product to honour an explicit allowlist entry.

An internal hostname is not more dangerous than a public one. The opposite is closer to the truth: it is the site the administrator controls end to end. Treating every non-public-suffix host as a "sensitive site" with no override, while a user or admin has explicitly added it to Allowed sites, inverts the trust model of an on-prem enterprise. `.local`, `.corp`, `.internal`, `.lan` are the normal case, not an edge case.

We will shortly have both ChatGPT and Claude users on our Macs. The ChatGPT desktop app drives our SAP without this friction. That is the comparison our users will make, and it will be hard to defend Claude on this point. We would much rather keep Claude.

## Additional details

- The agent cannot tell whether a prompt was shown; the tool result is identical whether the call passed or the user clicked Allow once. So the agent cannot degrade gracefully or warn the user in advance.
- The Allowed sites dialog strips `https://` when typed and URL-encodes `*`, so wildcard entries such as `*.habifino.local` cannot be created.
- Session cookies in the pane are lost on app quit (SAP asks for login again). Minor next to the above, mentioned for completeness.
- Same behaviour from Cowork (2026-08-30, 2026-09-06) and from Claude Code launched from the desktop app (2026-09-09).

### What Should Happen?

A host that an administrator has explicitly added to Allowed sites should be honoured by the built-in browser, regardless of whether its name sits under an ICANN public suffix. Either honour user/admin allowlist entries for internal hostnames, or provide an explicit setting (user or Team/Enterprise admin) that grants site-level permission for named internal hosts. If the sensitive-sites default is intentional, an explicit allowlist entry must override it. At minimum, document that internal hostnames are unsupported so customers can plan around it.

### Error Messages/Logs

```shell
Prompt shown on the first acting call (click) after a silent navigate + screenshot, 2026-09-09:

Allow Claude to access servdev.habifino.local?
Site-level permissions are disabled for this site. You'll be asked for each action.
{ "origin": "https://servdev.habifino.local" }
[Deny] [Allow once]

~/Library/Application Support/Claude/claude_desktop_config.json (excerpt, 2026-09-06):

"preferences": {
"launchPreviewAllowedOrigins": [
"https://servdev.habifino.local",
"https://servprdap1.habifino.local",
"https://ubuntu0.local.areastore.com"
],
"bypassPermissionsModeEnabled": true
}

Environment: macOS 26.6.2 (Apple silicon), Claude Desktop 1.49585.0, Claude Code CLI 2.1.195, Team plan. SAP GUI for HTML (webgui) on SAP ECC 7.40; both SAP hosts present AD-CA certificates trusted by the Mac.
```

### Steps to Reproduce

1. On a LAN, have any HTTPS site whose hostname is not under an ICANN public suffix, e.g. `https://anyhost.corp.local`, with a certificate the Mac trusts.
2. In Claude Desktop, Settings → Cowork → Allowed sites, add `anyhost.corp.local`. Set permission mode to "Skip all approvals" (or leave auto; result is the same).
3. Start Cowork, or Claude Code from the desktop app, and ask Claude to open the site in the built-in browser and click any link.
4. `navigate` and `screenshot` pass silently. The first click shows "Allow Claude to access anyhost.corp.local? Site-level permissions are disabled for this site. You'll be asked for each action." Every subsequent click/type/key prompts again.
5. Control: repeat with an equally internal, LAN-only host whose name sits under a public domain you own (e.g. `internal.example.com` resolving only on the LAN). Allowlisted, it drives silently.

Restarting the app, a fresh conversation, switching Preferred browser, and toggling bypass permissions mode make no difference.

### Claude Model

Other

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.195 (bundled with Claude Desktop, no separate CLI install)

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

No repository file or test is identified. Start by reproducing the permission prompt with an internal hostname and inspect how Settings → Cowork stores launchPreviewAllowedOrigins in claude_desktop_config.json, then trace the built-in browser's site-permission handling. Done means an explicitly allowlisted internal host permits acting calls without repeated prompts, with coverage for the public-suffix control case.

Escrito por el modelo de indexación a partir del texto del issue.