[FEATURE] Browser pane: let users trust public-TLD dev domains that resolve to loopback (Google OAuth rejects *.localhost and .test)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The Browser pane in Claude Desktop (Code tab) cannot show a local app that uses Google OAuth sign-in.

Two rules cause this problem:

• Google OAuth: The host of a redirect URI must end in a public top-level domain (TLD). The only exception is localhost or a loopback IP address. Google rejects a host such as app.example.localhost, app.example.test or app.example.local. We tested this. Google shows a redirect_uri error.
• Browser pane: The pane accepts only localhost, *.localhost, 127.0.0.1 and ::1 as local hosts. Our local stack uses a name with a public TLD, for example https://app.example.dev. The /etc/hosts file sends this name to 127.0.0.1. Google OAuth accepts this name.

When we open this name in the Browser pane and select "Always allow", the HTML loads. The pane then stops all scripts and API calls with ERR_BLOCKED_BY_CLIENT. The page is blank. The log file main.log shows this message: [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'script' }.

We also tried the workaround in #92698. We added the origins to launchPreviewPrivateNetworkReadOrigins. We added 127.0.0.1 for each origin in launchPreviewPrivateNetworkReadPins. The result did not change. These settings apply only to hosts on private network addresses, for example 10.x.x.x or 192.168.x.x. They do not apply to the loopback address of the computer.

Thus, no host name satisfies the two rules. A *.localhost name works in the Browser pane, but Google rejects it. A name with a public TLD works with Google, but the Browser pane blocks it.

Proposed Solution

Let the user trust a specific origin as a local development server. Apply this only when the host name resolves to a loopback address. The Browser pane must then process this origin as it processes localhost. This includes scripts, style sheets and API calls.

Two possible methods:

• Add a "Trust as local development server" option to the "allow this site" prompt. Show this option only when the host resolves to 127.0.0.1 or ::1.
• Add a documented setting that lists the trusted origins, for example https://app.example.dev and https://api.example.dev.

The user must have administrator rights to change /etc/hosts. Thus, the user already decided to send these names to the local computer. The opt-in is for each origin. The protection against DNS rebinding stays active for all other sites.

Alternative Solutions

• Use localhost for all of the local stack. This works with Google and with the Browser pane. But it is necessary to move many apps and one API to different ports or paths. These apps share one parent domain and its cookies.
• Use an OAuth proxy. Local sign-in then depends on a production server.
• Use a public tunnel, for example Cloudflare Tunnel or ngrok. The development computer is then open to the internet.
• Use Claude in Chrome to control the real Chrome browser. This works, but it does not use the Browser pane.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. The /etc/hosts file sends app.example.dev and api.example.dev to 127.0.0.1. A local reverse proxy serves the two names over HTTPS.
2. The Google Cloud Console has the redirect URI https://api.example.dev/auth/callback/google. Sign-in works in Chrome and in Safari.
3. In Claude Desktop, the agent opens https://app.example.dev in the Browser pane to examine a change to the user interface. The page is blank. The pane blocks all subresources with ERR_BLOCKED_BY_CLIENT.
4. With the proposed opt-in, the user trusts the two origins one time. The page loads. The agent can sign in with Google and test the flow.

Additional Context

• Claude Desktop 2.26454.2 on macOS.
• Related issues: #86228 (trust host names from the hosts file), #92698 (allow .test automatically), #86362 (the same blank page, closed), #47195 (*.localhost subdomains).
• This request gives one more reason for these issues. Names under *.localhost or .test do not solve the problem. OAuth providers such as Google do not accept them as redirect hosts. The name must use a public TLD.