Chrome’s Local Network Access Prompt: What Breaks for Localhost Dev (and When a Tunnel Is the Wrong Fix)

If a hosted frontend suddenly can’t reach your localhost:8080 API in Chrome, you have almost certainly met Local Network Access (LNA). Since Chrome 142, requests from public websites to local and loopback addresses sit behind a permission prompt. Chrome 156 reached Stable on October 20, 2026. It removed the temporary enterprise opt-out policy, so managed browsers can no longer downgrade these blocks to DevTools warnings.

This guide covers which developer setups break, how to read the confusing errors, why a tunnel URL makes the problem vanish, and why that is often the wrong fix.

TL;DR

• LNA gates requests from a public page to a local or loopback destination behind a per-site permission. If a user clicks Block, the connection stays broken until they reset the permission.
• Hosted frontends, third-party dashboards and iframes that call your dev server break. A localhost page calling localhost does not.
• Chrome 156 removes the LocalNetworkAccessRestrictionsTemporaryOptOut policy. That was the soft-landing mode for managed fleets.
• A tunnel works because the request now targets a public address. It swaps a user-consented path for an internet-reachable one.
• Prefer granting the permission, delegating it to iframes, or a narrow allowlist. Use a tunnel when you need inbound traffic or cannot control the embedding page.

What Is Chrome’s Local Network Access?

LNA supersedes Private Network Access (PNA), an earlier effort that used preflight requests so local devices could opt in. LNA drops the device opt-in and asks the user instead. Chrome’s developer blog compares it to the local network permissions on Android, iOS and macOS. Developers could try it from Chrome 138 by enabling chrome://flags/#local-network-access-check. Chrome 142 (Stable since October 28, 2025) turned the restriction on by default.

Google’s stated goals are to reduce cross-site request forgery against devices such as routers, and to make it harder for sites to fingerprint your local network.

A local network request is a request from a public website to a local IP address or loopback address, or from a local website (for example, an intranet) to loopback.

• Loopback means any destination that resolves to the machine itself, such as 127.0.0.0/8 and ::1.
• Local covers private address space. Atlassian’s bug report on the issue, for instance, lists 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Cloudflare’s documentation notes that the 100.64.0.0/10 range also counts as local.
• The permission exists only in secure contexts, so the calling page needs HTTPS.
• If granted, the permission also relaxes mixed-content blocking for those local requests, because many local devices cannot get publicly trusted certificates.

The permission prompt reads “Look for and connect to any device on your local network.”

Timeline: Chrome 138 to Chrome 156

Chrome	What changed
138	Opt-in via chrome://flags/#local-network-access-check
142	Restriction on by default, gated behind a permission prompt
145	Single permission split into local-network and loopback-network; the old name stays as an alias
146	New enterprise policies LocalNetworkAccessIpAddressSpaceOverrides and LocalNetworkAccessPermissionsPolicyDefaultEnabled
147	Restriction extended to WebSocket and WebTransport connections
156	LocalNetworkAccessRestrictionsTemporaryOptOut removed; Stable on October 20, 2026

Sources: Chrome’s guidance tracker entry, Chrome’s developer blog, Chrome Geek’s Chrome 156 coverage.

Which Localhost Dev Setups Break

The rule of thumb is a less-private origin calling a more-private destination. The prompt fires when a request moves inward from public toward local or loopback.

1. A hosted frontend calling localhost

This is the headline case. A preview or staging frontend on a public host calls an API on http://localhost:8080. Each end is fine on its own, but the public-to-loopback combination triggers the gate. If the user clicks Block, or the prompt never appears (see iframes below), the request fails.

2. Third-party platforms that load your dev server

Many vendor tooling flows work this way: the vendor’s public site loads or calls your local server. Developers have reported breakage in several of them:

• Shopify: Since Chrome 142, extensions served by the Shopify CLI with shopify app dev --use-localhost hit a CORS error (Shopify community).
• Adobe Express: Side-loading an add-on from https://localhost:5241 shows a prompt on new.express.adobe.com. If you click Block, side-loading fails (Adobe docs).
• Builder.io: The Visual Editor previewing localhost content can fail with net::ERR_BLOCKED_BY_LOCAL_NETWORK_ACCESS_CHECK after a Block (Builder.io docs).
• Twitch: An extension’s Local Test on https://localhost:8080 fails inside the Twitch dashboard iframe (Twitch forum).
• DatoCMS: Privately hosted plugins stopped working in Chromium browsers after the LNA change (DatoCMS community).

3. Iframes you don’t control

An embedded frame needs the permission delegated by the embedding page through Permissions Policy. Chrome 142 to 144 use allow="local-network-access". From Chrome 145 you can name local-network or loopback-network (Cloudflare’s summary). A Dynamsoft guide shows listing all three for compatibility.

Without delegation the failure can be silent. Atlassian’s bug report describes a Forge app frame where Chrome showed no prompt, so users had no chance to allow the request (ECO-1174). The Twitch thread describes the same pattern: the dashboard iframe does not request the permission, so Chrome refuses the request. If you don’t own the embedding page, you can’t add the attribute, which matters later in this article.

4. Live-reload and realtime sockets

Since Chrome 147, WebSocket and WebTransport connections are covered too. A hosted tool that opens a socket to your local dev server needs the same permission as one that calls fetch().

What does not break

• A page served from http://localhost:3000 calling http://localhost:8080. Both ends are loopback, so no inward step occurs.
• Setups where the user has already clicked Allow for that site and the permission has not been reset.

Reading the Error: LNA Looks Like CORS

Developers lose hours here because LNA failures often surface as CORS errors. Reports quote messages and annotations such as:

• Permission was denied for this request to access the 'unknown' address space (Atlassian and Dynamsoft)
• LocalNetworkAccessPermissionDenied in the DevTools network details (Twitch)
• net::ERR_BLOCKED_BY_LOCAL_NETWORK_ACCESS_CHECK (Builder.io)

LNA is a permission model, not a preflight handshake. The old PNA-era Access-Control-Allow-Private-Network response header is not the general fix. A Localtonet guide also stresses that CORS, mixed content, TLS and LNA are separate layers that can each fail on their own.

A debugging order that saves time:

1. Check whether the page origin is public and the destination is local or loopback.
2. Look for the prompt, or a blocked-permission indicator in the address bar.
3. If the request is inside an iframe, check the allow attribute.
4. Only then check CORS, mixed content and TLS.

One more trap: a Block sticks. Adobe’s docs say that after clicking Block you must reset the site’s permissions and data in Chrome’s site settings, then reload and click Allow.

What Chrome 156 Changes for Managed Browsers

LocalNetworkAccessRestrictionsTemporaryOptOut, supported since Chrome 142, let administrators make LNA failures show only DevTools warnings instead of blocking requests. Chrome’s guidance tracker says it is removed in Chrome 156. Chrome Geek confirms Chrome 156 hit Stable on October 20 and tells IT teams to replace setups that relied on the opt-out.

“Hard block” overstates the change slightly:

• Fleets that relied on the opt-out now get the default LNA handling. That means a prompt where a human can answer it.
• Where nobody can answer (kiosks, locked-down profiles, automated browsers), the request is likely to fail.
• Admins can still use an allowlist policy to grant named origins access. Kaltura’s guidance (updated August 2026) recommends LocalNetworkAccessAllowedForUrls and warns against disabling LNA globally. Cloudflare’s documentation says a policy named LocalNetworkAllowedForUrls replaces it from Chrome 146. Policy names have shifted, so check the current Chrome Enterprise policy list before deploying.

Dating caveat: older vendor documentation (Samsung Internet’s policy page, Cloudflare’s notes) said the opt-out would be removed after Chrome 152. Chrome’s own tracker and the Chrome 156 release coverage name 156, so treat 156 as the date that matters.

Why a Tunnel URL Sidesteps the Prompt

LNA classifies a request by the address space of its destination, evaluated after name resolution. A tunnel’s public hostname (for example https://abc123.tunnel-provider.example) resolves to the provider’s public edge. A hosted frontend calling that URL is making a public-to-public request, so the LNA check does not apply. The provider relays traffic to your machine over an outbound connection, which Chrome never sees.

Developers do reach for this. In the Twitch thread, a developer asked whether ngrok or Cloudflare Tunnel URLs would work for local testing. Another developer there avoids localhost entirely and points the extension at a real domain with a reverse SSH tunnel. The workaround works precisely because it is invisible to the browser’s policy.

The Security Cost of “Just Tunnel It”

LNA exists to put a human decision between a public website and your private network. A tunnel does not satisfy that control. It removes the question by making the service reachable from the whole internet.

The trade-offs:

1. Wider audience. An LNA grant is per site, per browser, and revocable. A tunnel URL is reachable by anyone who learns or guesses it, from any network, with no prompt.
2. Dev-grade services, prod-grade exposure. Local APIs often have permissive CORS, debug endpoints, seeded admin accounts and stack traces. These were tolerable behind loopback and are not safe on a public hostname.
3. No consent signal. Once tunnelled, the “do you trust this site” step is gone for every visitor, including crawlers and scanners.
4. A third party sits in the path. Many providers terminate TLS at their edge, so request bodies, tokens and cookies pass through infrastructure you don’t run.
5. Credential sprawl. Tunnel URLs get pasted into tickets, chat and .env files, and are left running after a task ends.
6. Policy conflicts. A tunnel can quietly route around controls your security team just deployed. In regulated environments that can be a policy violation, not just a risk.

If you do tunnel, put authentication in front of it, keep the URL short-lived, expose only the port you need, and never point it at a service holding real data. Stop or delete the tunnel when the test ends.

When a Tunnel Is the Wrong Fix

Reach for these first:

• Grant the permission once. For a single developer on a single site, clicking Allow is the least-privileged option. If you blocked it by mistake, reset the site’s permissions (Adobe documents the steps).
• Run the frontend locally. A localhost page calling localhost avoids the gate entirely. Use mkcert or your framework’s HTTPS dev mode when you need a secure context.
• Delegate to iframes. If you own the embedding page, add the allow attribute (loopback-network, local-network, and local-network-access for older Chrome), as Atlassian’s fix and Dynamsoft’s guide show.
• Use a narrow enterprise allowlist. List only the public origins that need access, not the local endpoints. Kaltura’s guidance calls any such allowlist a security exception that needs an owner, a documented reason and regular review. That is the right mental model. Verify the result in chrome://policy.
• Move the backend. A shared dev or staging environment removes the local-network hop altogether and suits team workflows better.
• Declare the target when you know it. Chrome’s design includes a targetAddressSpace fetch option for requests that intentionally target a local destination (Localtonet’s walkthrough shows an example). Triggering the request after a clear user action means people meet the prompt at a sensible moment.
• The flag is a last resort. Adobe, Builder.io and Atlassian document chrome://flags/#local-network-access-check as a workaround, and Adobe warns it applies to all websites. It is a per-browser escape hatch, so don’t build team workflows on it.

When a Tunnel Is the Right Fix

A tunnel is reasonable when:

• You need inbound traffic, such as webhooks from Stripe, Shopify or Slack. LNA does not address that at all.
• You are testing on real devices off your LAN.
• You must share a work in progress with a client or colleague.
• A third-party tool embeds your dev server in a frame you can’t modify, as with a vendor dashboard that won’t add the allow attribute.

In those cases, treat the tunnel as a deliberate, authenticated, time-boxed exposure, not a browser-prompt workaround.

What About Firefox and Safari?

Chrome is not alone. According to Dynamsoft’s rollout table, Firefox’s timeline was:

Firefox	Behavior
149	LNA enforced only for users with Enhanced Tracking Protection set to Strict
151	Gradual rollout to all users begins
153	Enforced by default for desktop users
154	Extended to WebSocket connections

Mozilla’s Firefox 154 release notes (first offered August 18, 2026) say that WebSocket connections to local network devices now ask for permission first. For admins, Firefox’s LocalNetworkAccess policy takes a SkipDomains list rather than an allowlist.

Safari is the outlier. A Sentry browser-updates radar entry from September 14, 2026 lists Safari as “No signal” for this feature. Switching browsers to dodge the prompt is a shrinking option.

Frequently Asked Questions

Does Chrome’s Local Network Access block localhost development?

Only when a public page calls a local or loopback address. A localhost page calling localhost isn’t affected.

Why does LNA show up as a CORS error?

Chrome blocks the request before the response is usable, and DevTools reports a failed cross-origin request. Look for the permission-denial text, such as LocalNetworkAccessPermissionDenied, before touching your CORS config.

Can I turn LNA off in Chrome 156?

Administrators lose the temporary opt-out policy. Users still have per-site permissions. Vendors have documented a Chrome flag as a workaround, but it is an unsupported per-browser escape hatch, not a long-term plan.

Is using a tunnel to avoid the prompt secure?

Not by default. It turns a consented, per-site path into a public URL. Add authentication, expose only what you need, and keep sessions short.

Sources

• Chrome for Developers: New permission prompt for Local Network Access
• GoogleChrome/modern-web-guidance-src #1127
• Chrome Geek: Chrome 156 is here
• Cloudflare: Host selectors (LNA notes)
• Samsung Internet: LocalNetworkAccessRestrictionsTemporaryOptOut
• Getsentry browser-updates-radar #29
• Dynamsoft: Chromium 142 LNA issue
• Shopify community thread
• Adobe Express known issues
• Builder.io integration tips
• Atlassian ECO-1174
• Twitch developer forum
• DatoCMS community
• Kaltura LNA guidance
• Localtonet: Chrome Local Network Access for APIs and WebSockets
• Firefox 154 release notes