#5191 · Browser session denies local connection permissions

BugPriority: MediumEffort: MediumdesktopsecurityGitHub issue

October 8, 2026 · trusted origin/main: 53c1e870d128c792dd3a0e469077cc4e6157b40d

PARTIALLY REPRODUCED · root-cause confidence: high for permission denial

1. TL;DR

The desktop browser installs a permission policy that grants only sanitized clipboard writes. Its real request and check handlers deny all three local-connection permission names supported by the pinned Electron version. A focused test exercised those production handlers after creating a browser tab, and the same three failures occurred in a second clean checkout. This establishes the local-connection blocker, not a complete Okta sign-in failure: this Linux environment has neither macOS Okta Verify nor an enrolled Okta test account. A safe repair needs an explicit local-network permission policy rather than a silent global grant, so no automated fix PR is opened.

2. Claims vs findings

Claim	Finding	Evidence
Browser permissions other than sanitized clipboard writes are denied.	Verified	The production predicate permits only `clipboard-sanitized-write`; both registered handlers call it. Existing permission controls pass.
Local-connection permissions are blocked.	Verified at the session boundary	Both handlers returned false for `local-network-access`, `local-network`, and `loopback-network` in both runs.
Okta Verify sign-in fails on the reported macOS installation.	Unverified end to end	No macOS host, Verify installation, or enrolled Okta test identity was available. The unit reproduction does not make a Chromium fetch or launch Verify.
A site setting can override the denial.	No override at this boundary	The registered handlers ignore origin and request details and synchronously use a fixed predicate. No mutable grant store or consent path is consulted here.
Importing authenticated cookies is a sufficient workaround.	Unverified	Cookie import was not attempted; no real account cookies or user runtime data were accessed.

Issue content was treated as untrusted claims. No supplied instruction, script, patch, or external evidence URL was executed or fetched.

3. Environment

Public repository: get-bb/bb; both checkouts use the exact trusted base above.
OS: Linux 4.19.0-gvisor; Node v22.19.0; pnpm 9.15.0; Vitest 4.1.1.
Trusted desktop package: bb 0.45.0, pinned Electron 44.3.0.
First clean checkout: <WORK>/base; second clean checkout: <WORK>/verify, a separate clone with detached HEAD at the same commit and origin set to the target repository.
Frozen installs succeeded in both checkouts. First turbo run build: 65 successful tasks. Second turbo run build --filter=@bb/desktop: 56 successful tasks.
No development app, server, browser UI, provider turn, fixed port, or persistent runtime data directory was used for the reproduction. Electron window/session objects use the repository's existing test fakes; the permission handlers themselves are production code.

4. Minimal reproduction

Clone trusted main and detach at the recorded commit:

git clone --branch main https://github.com/get-bb/bb.git bb-5191
cd bb-5191
git checkout --detach 53c1e870d128c792dd3a0e469077cc4e6157b40d
pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build --filter=@bb/desktop

Insert the focused test shown below inside describe("DesktopBrowserViewManager", ...) in apps/desktop/test/desktop-browser-view-manager.test.ts, immediately before the final test named allows clipboard-sanitized-write but denies clipboard-read and device permissions. This adds test cases only; it does not change production code. Run:
```
git diff --check
pnpm exec turbo run test --filter=@bb/desktop -- test/desktop-browser-view-manager.test.ts -t 'issue 5191'
```

The sign-in capability expectation is an allowed local-connection request through both handlers. Actual output from each checkout:

{"permission":"local-network-access","checkGranted":false,"requestGrants":[false]}
{"permission":"local-network","checkGranted":false,"requestGrants":[false]}
{"permission":"loopback-network","checkGranted":false,"requestGrants":[false]}

AssertionError: expected { checkGranted: false, …(1) } to deeply equal { checkGranted: true, …(1) }
Tests  3 failed | 77 skipped (80)
Exit status: 1

The assertion intentionally fails on the current policy. It demonstrates a missing capability; it is not a claim that every website should automatically receive this permission. This is a nonvisual session-policy reproduction, so no screenshot is fabricated.

Focused test, added inside the existing manager suite

This is the complete addition. It uses the existing owning suite's Electron fakes and tab fixture, without adding a production seam. The raw logs and test-only patch remain in the local investigation backup, not in this public repository.

  it.each(["local-network-access", "local-network", "loopback-network"])(
    "issue 5191: permits a local sign-in connection through both session handlers (%s)",
    (permission) => {
      const manager = createDesktopBrowserViewManager({
        partition: "persist:issue-5191",
      });
      const hostWindow = new FakeHostWindow({
        contentBounds: { width: 700, height: 450 },
        webContentsId: 74,
      });
      attachBrowserTab({
        manager,
        hostWindow,
        tabId: "browser:issue-5191",
        url: "https://example.com/",
      });
      const browserSession = electronMock.fakeSessions.at(-1);
      if (
        browserSession === undefined ||
        browserSession.permissionCheckHandler === null ||
        browserSession.permissionRequestHandler === null
      ) {
        throw new Error("Expected both production session handlers.");
      }
      const requestGrants: boolean[] = [];
      browserSession.permissionRequestHandler(null, permission, (granted) => {
        requestGrants.push(granted);
      });
      const result = {
        checkGranted: browserSession.permissionCheckHandler(null, permission),
        requestGrants,
      };
      console.log(JSON.stringify({ permission, ...result }));
      expect(result).toEqual({ checkGranted: true, requestGrants: [true] });
    },
  );

5. Root cause

The fixed browser permission predicate has one allowed value:

function isAllowedBrowserPermission(permission: string): boolean {
  return permission === "clipboard-sanitized-write";
}

Session hardening registers the same predicate for requests and checks:

const browserSession = session.fromPartition(partition);
browserSession.setPermissionRequestHandler((_wc, permission, callback) => {
  callback(isAllowedBrowserPermission(permission));
});
browserSession.setPermissionCheckHandler((_wc, permission) =>
  isAllowedBrowserPermission(permission),
);

Tab creation calls session hardening before creating its view. Therefore requests reaching this browser session cannot obtain local-network or loopback permission, regardless of origin. The pinned Electron declarations recognize all three tested permission names; the input was not an invented unknown permission. The deeper gap is a hardened default-deny browser without a local-connection consent/exception mechanism at this boundary. Whether the reported FastPass installation reaches this specific Chromium permission gate remains an end-to-end experiment.

Trusted package version evidence: desktop version and Electron dependency. Existing permission test: current allow/deny contract.

6. Proposed fix and simple-fix decision

Decide how a human grants local-connection access to a specific requesting origin while preserving default denial for arbitrary sites and automation. Then make both permission handlers consult the same grant decision and test approved, denied, and unapproved origins, including loopback. Avoid a global local-network grant: it expands website access to host-local services, not just sign-in. The regression expectation should be adapted to an explicitly approved origin once that policy is selected.

No fix branch or PR: any repair changes a permission/security boundary and requires a product policy decision, both explicitly outside this rule's simple-fix conditions. End-to-end macOS verification is also incomplete. No production code was changed, no dependency was added, and no branch was pushed. GitHub cross-reference metadata and an open-PR search for the numeric issue found no existing linked open PR during investigation.

7. Verification

The same agent repeated the reproduction in a second clean checkout; this is a repeatability check, not independent verification. The second clone used the exact same trusted SHA, had no test modifications until the report-owned patch was applied, and received its own frozen install and desktop dependency build. No application ports or persistent data were needed.

Second checkout: <WORK>/verify
HEAD and origin/main: 53c1e870d128c792dd3a0e469077cc4e6157b40d
pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build --filter=@bb/desktop
git apply <REPORT>/issues/5191/repro/permission-handlers.patch
pnpm exec turbo run test --filter=@bb/desktop -- test/desktop-browser-view-manager.test.ts -t 'issue 5191'
Result: exit 1; 3 failed, 77 skipped; both handlers deny every tested permission.
git diff --check
Result: exit 0.

After removing the test-only patch from the first checkout, its unchanged existing owner suite passed:

git apply -R <REPORT>/issues/5191/repro/permission-handlers.patch
pnpm exec turbo run test --filter=@bb/desktop -- test/desktop-browser-view-manager.test.ts
Test Files  1 passed (1)
Tests  77 passed (77)
Exit status: 0

No report correction was necessary: the second run confirmed the denial mechanism. The final verdict remains PARTIALLY REPRODUCED because the actual macOS/Okta browser flow was not exercised.

8. Related issues

#5114 concerns macOS passkey support in the desktop browser. It is a different authentication capability, not evidence that this local-connection blocker is fixed or duplicated.

9. Appendix

Investigation command ledger (checkout paths normalized):
git clone --depth 1 --branch main https://github.com/get-bb/bb.git <WORK>/base
git -C <WORK>/base fetch origin main
git -C <WORK>/base rev-parse origin/main
cd <WORK>/base
pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build
Added the inline test via apply_patch.
git diff -- apps/desktop/test/desktop-browser-view-manager.test.ts
git diff --check
pnpm exec turbo run test --filter=@bb/desktop -- test/desktop-browser-view-manager.test.ts -t 'issue 5191'

git clone --no-hardlinks <WORK>/base <WORK>/verify
git -C <WORK>/verify remote set-url origin https://github.com/get-bb/bb.git
git -C <WORK>/verify checkout --detach 53c1e870d128c792dd3a0e469077cc4e6157b40d
cd <WORK>/verify
pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build --filter=@bb/desktop
Applied the same test-only patch and repeated the focused command.
git diff --check

cd <WORK>/base
Removed the test-only addition, then ran the unchanged manager suite.
git status --short
Result: clean.

Read trusted browser manager, owning tests, desktop package, and Vitest config.
Searched permission references in desktop, desktop-contract, plugin-sdk, and browser-automation.
Read pinned Electron permission-handler declarations.
Read issue 5191 properties, comments, labels, and cross-reference metadata.
Read neighboring desktop classifications and related issue 5114 metadata.
gh pr list --repo get-bb/bb --state open --search '5191' --json number,state
Result: []
git -C <WORK>/base fetch origin main
Result: base still matches latest trusted main.

Root-cause permalinks and excerpts were checked against the recorded base in both checkouts. The result blocks contain real test output with temporary checkout locations normalized to placeholders; no credentials, real browser cookies, user runtime data, or home-directory paths are published. Raw evidence stays outside public git in the local backup, following this report repository's publication rules.

AGENT GENERATED