### Preflight Checklist - [x] I have searched existing issues and this hasn't been reported yet (closest is #91547, which is Duo Desktop; no Okta FastPass report exists) - [x] This is a single bug report - [x] I am using the latest version of Claude Code ### What's Wrong? The Claude Desktop Browser pane never grants Chromium's Local Network Access permission for loopback. Okta FastPass authenticates by calling the Okta Verify desktop app on `127.0.0.1`, so every FastPass attempt in the pane

[BUG] Desktop Browser pane denies Chromium Local Network Access (loopback-network), so Okta FastPass can't reach Okta Verify and Okta-protected sites are unusable

Status Open

Reported on v2.1.278

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 0 comments · opened Oct 2, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet (closest is #91547, which is Duo Desktop; no Okta FastPass report exists)
[x] This is a single bug report
[x] I am using the latest version of Claude Code

What's Wrong?

The Claude Desktop Browser pane never grants Chromium's Local Network Access permission for loopback. Okta FastPass authenticates by calling the Okta Verify desktop app on 127.0.0.1, so every FastPass attempt in the pane fails with:

Okta FastPass requires network permission Unable to sign in. The browser is blocking communication with Okta Verify.

Console:

Uncaught (in promise) CHROME_LOCAL_NETWORK_ACCESS_DENIED_ERROR: Chrome Local Network Access permission was denied for FastPass.
    at g (https://ok3static2.oktacdn.com/assets/js/sdk/okta-signin-widget/7.49.0/js/okta-sign-in.min.js:82:458636)

Okta's remediation ("open site settings → Local network access / Apps on device → Allow") is impossible because the pane has no permission prompt, no site-settings UI, no chrome:// pages, and no support for the LocalNetworkAccessAllowedForUrls enterprise policy.

For organizations whose Okta sign-on policy requires desktop Okta Verify as the second factor (ours does for GitLab), there is no alternate factor offered, so every Okta-protected internal site is unreachable in the Browser pane. In our case that includes our self-hosted GitLab, which means Claude cannot open merge requests in the pane.

This is the same root cause as #91547 (Duo Desktop device-health check). Okta is a second major enterprise IdP hitting the identical gap. The same bug was reported against another Electron-based coding tool (pingdotgg/t3code#9724), and the ChatGPT/Codex desktop app shipped a fix for Okta sign-in in its built-in browser in August 2026.

What Should Happen?

Either (a) the pane shows Chromium's Local Network Access permission prompt and, once allowed, FastPass completes against Okta Verify on loopback, or (b) the pane grants loopback-network for the sign-in origin automatically (as it is a same-device loopback request, not a LAN scan), or (c) there is a user/admin allowlist for origins permitted to make loopback requests.

Error Messages/Logs

The page shows "Okta FastPass requires network permission — The browser is blocking communication with Okta Verify."
Console logs CHROME_LOCAL_NETWORK_ACCESS_DENIED_ERROR.
Network log shows POST /idp/idx/authenticators/okta-verify/launch → 200 and POST /idp/idx/authenticators/poll → 200, i.e. Okta's server side is fine; only the loopback call from the page to Okta Verify is denied.
The "Open Okta Verify" custom-protocol handoff also never surfaces an OS prompt in the pane, so that path loops forever too.
No prompt is ever shown, and there is no setting anywhere in the app to grant the permission.

Steps to Reproduce

Be in an Okta org where an app's sign-on policy requires Okta Verify (FastPass or desktop Okta Verify) as a factor.
In Claude Desktop → Code tab, open the Browser pane (Cmd+Shift+B) and navigate to a URL behind that app, e.g. a self-hosted GitLab MR URL.
Observe the redirect to https://<org>.okta.com/app/.../sso/saml?SAMLRequest=.... The sign-in page renders correctly.
Click Sign in with Okta FastPass.

Is this a regression?

Not sure. The Local Network Access gate arrived with Chromium 142, so the pane may have worked on older Electron builds; it has failed on every Desktop build I have used since at least Aug 2026.

Claude Code Version

Claude Desktop 2.19675.0 (Electron 44.4.3 / Chrome 152.0.7977.130), Claude Code CLI 2.1.278

Platform

Claude Desktop app (Code tab, Browser pane)

Operating System

macOS 26.7 (25G229)

Terminal/Shell

N/A (Desktop app Browser pane)

Additional Information

| Item | Value |
|---|---|
| Claude Desktop | 2.19675.0 (macOS universal) |
| Electron / Chromium | Electron 44.4.3 / Chrome 152.0.7977.130 |
| Claude Code CLI | 2.1.278 |
| macOS | 26.7 (25G229) |
| Okta Sign-In Widget | 7.49.0 |
| Okta Verify | desktop app installed and working in Chrome/Safari on the same machine |
| Plan | Enterprise |

Root cause (as far as I can tell)

Chromium 142+ gates loopback and private-network subresource/fetch requests behind the Local Network Access permission. Chrome shows a prompt ("Look for and connect to any device on your local network" / "Access other apps and services on this device"); enterprises pre-allow IdPs via LocalNetworkAccessAllowedForUrls.
Electron exposes this to embedders as the local-network, loopback-network (and legacy local-network-access) permission types in session.setPermissionRequestHandler / setPermissionCheckHandler. Electron itself does not grant it by default (electron/electron#48655 closed as not planned).
The Browser pane's session appears to have no handler that allows these permission types, so the check is denied silently.

Suggested fix

Any of the following would unblock Okta, Duo, and other loopback-based SSO helpers:

In the Browser pane's permission handlers, allow loopback-network (and legacy local-network-access for the loopback case) for top-level sign-in origins, or at minimum surface Chromium's prompt in the pane so the user can approve it. Loopback is same-device only; it does not expose the LAN.
Add a managed/user setting to allowlist origins for local-network access, mirroring Chrome's LocalNetworkAccessAllowedForUrls (e.g. [*.]okta.com, [*.]duosecurity.com), ideally alongside the existing Claude in Chrome site allowlist.
Until then, document in the Desktop docs that Okta FastPass, Duo Desktop, and similar loopback-based factors cannot complete in the Browser pane.

Workarounds tried

Cookie import from Chrome: works only while the imported Okta session is still MFA-fresh. As soon as Okta requires re-verification, the same block occurs. Import itself also fails intermittently on macOS (#95088).
Persist sessions: doesn't help, since the initial sign-in can never complete.
Claude in Chrome extension: works, because real Chrome has the permission, but it serializes on the user's everyday browser and defeats the point of per-session parallel Browser panes (#87764).

Related issues

#91547 — Browser pane can't grant local-network/loopback permission (Duo Desktop) — same root cause
#87764 — no way to use existing browser login state in the Browser pane
#80293, #87854 — cookie/session persistence in the pane
#95088 — Chrome cookie import fails on macOS (keychain)
pingdotgg/t3code#9724 — identical FastPass failure in another Electron-based coding tool
Chrome: https://developer.chrome.com/blog/local-network-access
Okta: https://help.okta.com/eu/en-us/content/topics/end-user/ov-device-lna-prompt.htm
Electron: https://www.electronjs.org/docs/latest/api/session (permission types local-network, loopback-network, local-network-access)

Happy to provide screenshots, a HAR, or test a build with the permission granted.

View original on GitHub ↗