[BUG] Browser pane treats NAT64 addresses (64:ff9b::/96) as private network, blocking every IPv4-only public site

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?

On a network that does DNS64/NAT64 (typical of mobile carriers and phone hotspots), the built-in browser pane treats every IPv4-only public site as if it were on a private network. Navigating to one shows the "This site is on a private network." prompt, and after the document loads with 200, its subresources and XHRs fail with net::ERR_BLOCKED_BY_CLIENT. Sites with native IPv6 load normally on the same network.

On such a network an AAAA lookup for an IPv4-only host returns a synthesized address in the NAT64 well-known prefix 64:ff9b::/96 (RFC 6052), with the public IPv4 address in the low 32 bits: github.com comes back as 64:ff9b::14c8:f5f7, which is 20.200.245.247. The IANA special-purpose registry lists 64:ff9b::/96 as globally reachable; only 64:ff9b:1::/48 (RFC 8215) is local-use. The pane appears to classify the whole prefix as non-public instead of classifying the IPv4 address it embeds.

This may be the root cause behind #89725 (public domain, document 200, every subresource ERR_BLOCKED_BY_CLIENT) and some reports under #87472.

What Should Happen?

A 64:ff9b::/96 address should be classified by the IPv4 address it embeds: 64:ff9b::14c8:f5f7 (20.200.245.247) is public, while 64:ff9b::7f00:1 (127.0.0.1) and 64:ff9b::a00:1 (10.0.0.1) are not. 64:ff9b:1::/48 should stay private. Public IPv4-only sites then load without the prompt, and the prefix does not become a way around the private-network guard.

Error Messages/Logs

NAT64 confirmed on the machine (RFC 7050 discovery):

$ dig +short AAAA ipv4only.arpa
64:ff9b::c000:aa
64:ff9b::c000:ab

From a page on https://example.com/ in the pane, loading a cache-busted <img> from each host:

| Host | AAAA answer | In the pane | curl on the same machine |
|---|---|---|---|
| www.google.com | native 2001:4860:… | loaded | |
| t1.daumcdn.net | native 2001:290:… | loaded | |
| raw.githubusercontent.com | native 2606:50c0:… | loaded | |
| github.com | NAT64 64:ff9b::14c8:f5f7 | error | 200 image/x-icon |
| place.map.kakao.com | NAT64 64:ff9b::d3f2:e82 | error | 200 image/x-icon |
| map.kakao.com | NAT64 64:ff9b::d3f2:c86 | error | 200 image/x-icon |

read_network_requests after navigating the pane to a public Kakao Map place page:

GET https://place.map.kakao.com/8508642                -> 200
GET https://place.map.kakao.com/place/is-login-user/   -> FAILED net::ERR_BLOCKED_BY_CLIENT
GET https://place.map.kakao.com/places/panel3/8508642  -> FAILED net::ERR_BLOCKED_BY_CLIENT

The page then shows only its "could not load data" state.

Steps to Reproduce

1. Put the Mac on a network that does DNS64/NAT64, e.g. a phone hotspot on a carrier that uses 464XLAT. dig +short AAAA ipv4only.arpa should return 64:ff9b::….
2. Open https://example.com/ in the Claude Desktop browser pane.
3. In the page, run:

``js
for (const u of ['https://www.google.com/favicon.ico', 'https://github.com/favicon.ico']) {
const i = new Image();
i.onload = () => console.log('ok', u);
i.onerror = () => console.log('blocked', u);
i.src = u + '?x=' + Date.now();
}
`
Google (native IPv6) logs ok; GitHub (IPv4-only, so NAT64) logs blocked`.

1. Navigate the pane to any IPv4-only site, e.g. https://place.map.kakao.com/8508642: the private-network prompt appears and the page's own requests fail with ERR_BLOCKED_BY_CLIENT.

Claude Model

Other

Is this a regression?

I don't know

Claude Code Version

2.1.286 (Claude Desktop 2.19675.0, built-in browser pane, not the Chrome extension)

Platform

Anthropic API

Operating System

macOS 27.0.1 (Apple Silicon)

Terminal/Shell

Claude Desktop (Code tab)

Additional Information

The machine is dual-stack on that network: a private IPv4 address behind the hotspot, and IPv6 from the carrier with DNS64. Hosts with native AAAA records connect over ordinary global IPv6 and are unaffected; only hosts without AAAA records get the synthesized 64:ff9b:: address, and exactly those are blocked.