← reports

#3059 · Embedded desktop browser does not inherit sign-in state

Bug Medium Effort: High desktop open on GitHub 2026-09-04 · base d39bca3

Verdict: REPRODUCED · Root-cause confidence: high

1. TL;DR

Desktop links are intentionally routed into bb’s embedded browser when that preference is enabled. The desktop shell creates those views in a dedicated persistent Electron partition, and the session setup neither imports sign-in cookies from another browser nor rewrites Electron’s application-identifying user agent. A focused regression test demonstrates the missing user-agent hardening twice at the same trusted commit, while repository-wide source inspection confirms there is no external-profile cookie transfer into this partition. The exact behavior of individual third-party login pages was not exercised because the report’s external links and account state are untrusted and unavailable.

Trust note: The issue title, body, comments, links, code, and suggested implementation were treated as untrusted claims. No linked repository, branch, patch, command, or external page was opened or executed.

2. Claims vs findings

ClaimStatusEvidence
Enabled desktop links open inside the app.VerifiedThe routing function selects in-app-browser for HTTP(S) URLs when desktop support and the preference are enabled. Its nine focused tests passed in both clean checkouts.
The embedded view uses a separate persistent Electron session.VerifiedThe manager’s default partition is persist:bb-browser, and ensureHardenedSession obtains it through session.fromPartition.
The embedded session inherits sign-in cookies from the person’s regular browser.RefutedNo desktop production path reads an external browser profile or writes cookies into the embedded partition. The only session initialization in the browser manager installs permission and download handlers.
The embedded session removes Electron/application identity from its user agent.RefutedThe focused regression test expected one sanitized user-agent assignment and observed zero in both trusted checkouts.
Specific third-party services reject or degrade this embedded session.Unverified directlyNo third-party page or account was used. The verified session conditions explain why a previously authenticated regular-browser profile cannot make this partition authenticated.

3. Environment

4. Minimal reproduction

  1. Clone trusted get-bb/bb and detach at d39bca3ebfa8e00ffcb9810b7d333a03f12c2bb0.
  2. Install and build with:
    pnpm install --frozen-lockfile --prefer-offline
    pnpm exec turbo run build
  3. Apply the focused regression patch. It extends the existing Electron session fake to record user-agent assignments and adds this test:
    it("removes application identity tokens from the embedded browser user agent", () => {
      const manager = createDesktopBrowserViewManager({
        partition: "persist:test",
      });
      const hostWindow = new FakeHostWindow({
        contentBounds: { width: 700, height: 450 },
        webContentsId: 75,
      });
    
      attachBrowserTab({
        manager,
        hostWindow,
        tabId: "browser:a",
        url: "https://artifact.invalid/",
      });
    
      const fakeSession = electronMock.fakeSessions.at(-1);
      expect(fakeSession).toBeDefined();
      expect(fakeSession?.userAgentCalls).toHaveLength(1);
      expect(fakeSession?.userAgentCalls[0]).not.toMatch(/\b(?:Electron|bb)\//u);
    });
  4. Run the focused test:
    cd apps/desktop
    pnpm exec vitest run test/desktop-browser-view-manager.test.ts \
      --config vitest.config.ts \
      -t 'removes application identity tokens'

Expected: the manager assigns a browser-compatible user agent with no Electron or bb product token.

Actual in both checkouts:

AssertionError: expected [] to have a length of 1 but got +0

Test Files  1 failed (1)
Tests  1 failed | 32 skipped (33)
exit_code=1

The unchanged manager suite passed first in the second checkout: 32 passed. Full captured results are in test-output.txt.

5. Root cause

The app layer routes all eligible HTTP(S) links to the embedded browser whenever the desktop feature and preference are enabled; it does not distinguish hosts that require a regular-browser identity. See in-app-browser-link-preference.ts lines 27–39.

if (desktopBrowserAvailable && openLinksInAppBrowser) {
  return "in-app-browser";
}
return "external-browser";

The desktop manager then defaults every embedded view to a dedicated persistent partition. See the partition constant and manager initialization.

const BB_BROWSER_PARTITION = "persist:bb-browser";
const partition = args.partition ?? BB_BROWSER_PARTITION;

Finally, ensureHardenedSession obtains that partition and only installs permission and download policy. It does not transfer sign-in state or set a user agent before a view is created. See desktop-browser-view.ts lines 430–445 and view creation lines 701–705. Repository search at the base commit finds fromPartition here but no setUserAgent or cookie get/set in this manager.

The visible result follows directly for any service whose authenticated state exists only in another browser profile: bb loads it in a different cookie jar, so the request is unauthenticated. The user-agent omission is a second verified compatibility defect, but correcting it alone would not copy authentication state.

6. Proposed fix (first principles)

First, sanitize the embedded session’s user agent once during session hardening and retain a focused unit test. Separately, make an explicit product and security decision for sign-in state: either route affected authentication-heavy hosts to the system browser, add a user-controlled import flow with a narrowly documented host allowlist and clear consent, or support a browser-owned authenticated handoff. Any import design must define profile selection, OS-specific decryption, refresh, failure reporting, revocation, and the trust boundary before code is accepted. A user-agent-only patch is insufficient for the reported signed-in behavior.

7. Related issues

8. Appendix

Verification

The same agent created a second clean clone, checked out the exact base commit, ran a frozen install and dependency-aware desktop build, confirmed the unmodified manager suite passed all 32 tests, applied the same reproduction patch, and repeated the focused failure with the same assertion. The nine existing URL-routing tests passed in both checkouts. No report claim was changed after verification.

Commands run

git clone https://github.com/get-bb/bb.git target-primary
git clone https://github.com/get-bb/bb.git target-verify
git -C target-primary checkout d39bca3ebfa8e00ffcb9810b7d333a03f12c2bb0
git -C target-verify checkout d39bca3ebfa8e00ffcb9810b7d333a03f12c2bb0
pnpm install --frozen-lockfile --prefer-offline
pnpm exec turbo run build
pnpm exec turbo run build --filter=@bb/desktop
pnpm exec vitest run test/desktop-browser-view-manager.test.ts --config vitest.config.ts
pnpm exec vitest run test/desktop-browser-view-manager.test.ts --config vitest.config.ts -t 'removes application identity tokens'
pnpm exec vitest run src/lib/in-app-browser-link-preference.test.ts --config vitest.config.ts
git grep -n -E 'setUserAgent|fromPartition|cookies\.(get|set)' d39bca3ebfa8e00ffcb9810b7d333a03f12c2bb0 -- apps/desktop/src

Limitations

A real Electron main-process probe was attempted with an isolated temporary user-data path, but this headless host never reached Electron’s ready event; it was terminated and excluded from evidence. No external service behavior, browser database format, cookie decryption, or account-specific claim is asserted by this report.