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

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.

Start in apps/desktop by locating the integrated browser and auth-window setup, then inspect how browser permissions are handled. Reproduce the Okta FastPass flow on macOS using the steps in the issue. Done means loopback-based authentication can reach Okta Verify and complete inside T3 Code without requiring an external browser.