# fix\(desktop\): browser tabs no longer report loopback access as denied · PR \#22835 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/pull/22835)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: open

Source repository: Unavailable fork

Source branch: fix/preview-loopback-permission

Target branch: main

Head commit: aa91fc99dfd062d72bb79d3953d8100a8d602b2b

[Discussion and reviews](https://git.cafe/pingdotgg/t3code/pull/22835)

[Commits](https://git.cafe/pingdotgg/t3code/pull/22835/commits?format=markdown)

[Files changed](https://git.cafe/pingdotgg/t3code/pull/22835/diffs?format=markdown)

## Description

---

## Problem

Okta sign-in fails inside the built-in browser. Every factor, including password, stops at "Okta FastPass requires network permission" (#9724, three independent reports on macOS).

Browser tabs can already reach `127.0.0.1`. Electron never asks the preview session for permission before a loopback request. But the session's check handler answers `denied` for `loopback-network`, so `navigator.permissions.query` reports a block that does not exist. Okta's sign-in widget reads that state before it contacts Okta Verify, and gives up.

Repro: open any Okta tenant with FastPass in a browser tab, with Okta Verify running.

## Change

Add `loopback-network` to the preview permission allowlist, so the check handler matches what the browser already does.

```diff
 const ALLOWED_PREVIEW_PERMISSIONS = new Set([
   "clipboard-read",
   "clipboard-sanitized-write",
   "geolocation",
   "fullscreen",
+  // Electron 44 does not gate loopback requests behind this permission ...
+  "loopback-network",
 ]);
```

`local-network` (other devices on the LAN) stays denied. The legacy `local-network-access` name also stays denied, because Okta only falls back to it when the `loopback-network` query throws, and Chromium 152 supports `loopback-network`.

## Scope and approval

Fixes #9724, which is not triaged yet. I think this qualifies as a small fix for an obvious bug. The permission check contradicts the browser's actual behavior, and the fix is one allowlist entry that makes it truthful. Pages gain no new network access, since loopback requests already succeed. If a future Electron starts enforcing loopback access through the request handler, tabs keep today's behavior because the same allowlist answers both handlers.

A per-site prompt, which commenters on #9724 suggested, would be a new feature and is out of scope.

## Verification

**Permission state vs. real behavior.** Electron 44.9.3 / Chromium 152.0.7977.167 (the version main pins), a fresh partition with the preview handlers, public page `https://example.com`, request to a local `127.0.0.1` server:

| | `loopback-network` | `local-network` | `fetch("http://127.0.0.1:…")` |
|---|---|---|---|
| main | denied | denied | 200 |
| this branch | granted | denied | 200 |

The request handler was never called in either run.

**Okta, end to end.** macOS, `vp run dev:desktop` from this branch, no `--disable-features` flags, a real Okta tenant with FastPass:

- Before (current nightly): sign-in stops at "Okta FastPass requires network permission".
- After: Okta hands off to Okta Verify ("Verifying your identity") and sign-in completes. The signed-in page shows internal data, so the screenshot stops at the hand-off.

| Before (nightly) | After (this branch) |
|---|---|
| <img src="https://raw.githubusercontent.com/afrojun/t3code/b29d9d2564dacbe61f3b020d8044ecadf7570a0d/before.png" width="360" alt="Okta: FastPass requires network permission"> | <img src="https://raw.githubusercontent.com/afrojun/t3code/b29d9d2564dacbe61f3b020d8044ecadf7570a0d/after.png" width="360" alt="Okta: Verifying your identity with Okta Verify"> |

DevTools on the Okta page in the tab (⋮ → Open DevTools):

```text
loopback-network granted
local-network denied
```

**Unit test.** `BrowserSession.test.ts` now asserts that both handlers allow `loopback-network` and deny `local-network` and `local-network-access`. `vp test run apps/desktop/src/preview/BrowserSession.test.ts` passes 7/7. With the source line reverted, it fails with `request handler should allow loopback-network`.

`vp lint`, `vp fmt --check`, `git diff --check` and `vp run --filter @t3tools/desktop typecheck` are clean.

Not checked: Windows and Linux, and loopback SSO helpers other than Okta Verify. The manual Okta run used this change on an older main. After rebasing, the source change is identical and the unit test, lint and typecheck were rerun.

🤖 Generated with [Claude Code](https://claude.com/claude-code) using Claude Opus 5.5