[Bug]: Integrated browser denies Local Network Access, so Okta FastPass (and other loopback SSO helpers) cannot authenticate

[andybergon]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Use a corporate identity provider whose MFA relies on a local companion app reached over loopback. Okta FastPass is the concrete case: it authenticates by having the browser call the Okta Verify desktop app on 127.0.0.1.
2. In T3 Code's integrated browser, start a sign-in that redirects to the Okta SSO screen (e.g. connecting to a GitHub Enterprise Cloud org that enforces Okta SSO).
3. Reach the FastPass verification step.

Expected behavior

FastPass reaches Okta Verify over loopback and the sign-in completes inside T3 Code, the same way it does in a normal Chrome/Edge window.

Actual behavior

FastPass fails with "Okta FastPass requires network permission — The browser is blocking communication with Okta Verify," and tells the user to change "Local network access" / "Apps on device" from Block to Allow in browser site settings. The integrated browser exposes no site-settings UI to grant that permission, so the flow dead-ends.

The cause appears to be Chromium's Local Network Access permission (shipped around Chrome 138), which gates the loopback request FastPass makes to Okta Verify. This build's integrated browser is on Chromium 150, where the gate is active, and the app does not register a permission handler to allow it for the auth window. So any loopback-based SSO helper is blocked, not just Okta.

This is distinct from #6561 / #8435, which fixed window.open() OAuth popups in the preview. That work restores popup auth flows but does not grant Local Network Access to a loopback helper, so FastPass is still blocked after it.

Impact

Blocks enterprise SSO sign-in from inside T3 Code. Users on Okta FastPass (and similar loopback MFA) cannot connect to SSO-gated services in the integrated browser and must fall back to an external browser or a different MFA factor.

Version or commit

0.0.39-nightly.20260904.1278 (Electron 43.4.1 / Chromium 150.0.7871.224)

Environment

macOS

Logs or stack traces

No response — the failure surfaces only as the Okta FastPass "requires network permission" screen; no app-side error.

Screenshots, recordings, or supporting files

The FastPass screen reads "Okta FastPass requires network permission / Unable to sign in / The browser is blocking communication with Okta Verify," followed by the site-settings instructions and a "Verify with something else" link. Full screenshot available on request.

Workaround

On the Okta screen, choose "Verify with something else" and use a factor that does not need the loopback helper (push, TOTP, or a security key); or complete the sign-in in the system default browser, which already has local network permission.

[andybergon]

Still reproduces on a newer build: 0.0.41-nightly.20260910.1486 (macOS), so this is not resolved as of the Sep 10 nightly.

The block is broader than the FastPass button: choosing "Verify with something else" and other factors (including password) all fail with the same "Okta FastPass requires network permission" error inside the integrated browser, so the loopback gate effectively dead-ends the entire Okta sign-in. The only escape is to complete sign-in in an external browser.

One correction to the original report: this build does register a permission handler on the integrated browser's Electron session. In the installed bundle, the preview session's setPermissionRequestHandler / setPermissionCheckHandler grant only an allowlist of clipboard-read, clipboard-sanitized-write, notifications, and geolocation. local-network-access is not in that set, so the Local Network Access request Okta makes for the 127.0.0.1 loopback to Okta Verify is denied for every preview page, with no site-settings UI to override it.

The bundle does contain local-network-access handling elsewhere, but only in the bundled Playwright CDP grantPermissions path used by agent preview automation and the trace viewer; the interactive login window does not go through it.

Environment: macOS, integrated browser on Chromium 150.

[homatthew]

Facing the same issue when using Okta with the T3 Code browser on 0.0.43-nightly.20260925.2251 (macOS).

What I found + a local workaround

Electron 44.4.2, Chromium 152.

The loopback request isn't what's blocked. Electron already runs with --disable-features=LocalNetworkAccessChecks, so the request goes through. What fails is the permission check: the preview session's setPermissionCheckHandler only allows what's in ALLOWED_PREVIEW_PERMISSIONS, and the local network permissions aren't there.

Okta's widget (okta-sign-in.min.js 7.49.0) asks for the permission state before it ever talks to Okta Verify. It gets denied, shows the "requires network permission" screen, and stops. That's why every factor fails, not just FastPass.

Quick check from DevTools on any https page in the T3 browser, with Okta Verify running:

for (const name of ['loopback-network', 'local-network-access', 'local-network'])
  console.log(name, (await navigator.permissions.query({ name })).state);
console.log('probe', (await fetch('http://127.0.0.1:8769/probe')).status);

All three come back denied, and the probe comes back 200.

I added local-network-access, local-network and loopback-network to that allowlist in my local app.asar. After that the query returns granted, and Okta sign-in works in the T3 browser.

A global grant probably isn't what you want (see #8291). A Chrome-style per-site prompt would fix it, as long as the check handler returns the saved choice.

[tensorcopy]

Adding a +1, plus a few points that might help triage:

• This is broader than Okta FastPass. Any loopback-based SSO/MFA helper is gated by the same check. The preview session's permission allowlist (ALLOWED_PREVIEW_PERMISSIONS in the setPermissionCheckHandler / setPermissionRequestHandler) only covers clipboard-read, clipboard-sanitized-write, notifications, and geolocation — none of the Chromium local-network permission names (local-network-access, local-network, loopback-network). As a result, navigator.permissions.query() returns denied for every page in the integrated browser, and auth widgets that check permission state before connecting (like Okta's) dead-end even when the loopback request itself would succeed.
• A minimal fix looks low-risk. Since Electron already runs with --disable-features=LocalNetworkAccessChecks (per the analysis in the comment above), extending the allowlist with the local-network permission names should be enough to unblock loopback SSO flows without weakening anything else.
• If a global grant is a concern (in line with fix(desktop): stop granting preview content clipboard-read and geolocation #8291's work on tightening over-broad auto-granted preview permissions), a Chrome-style per-site prompt or a settings toggle for the integrated browser would be the cleaner long-term fix.
• Impact: enterprise users behind Okta-enforced SSO (e.g., GitHub Enterprise Cloud orgs) currently cannot complete sign-in from inside T3 Code at all and have to fall back to the system browser.

Would love to see either the allowlist extended or a per-site prompt. Happy to help test a nightly with the fix.