[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 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

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_