#3059 · Embedded desktop browser does not inherit sign-in state
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
| Claim | Status | Evidence |
|---|---|---|
| Enabled desktop links open inside the app. | Verified | The 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. | Verified | The 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. | Refuted | No 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. | Refuted | The 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 directly | No 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
- Repository:
get-bb/bb, trustedorigin/maincommitd39bca3ebfa8e00ffcb9810b7d333a03f12c2bb0. - Primary checkout and a second clean checkout were both detached at that exact commit.
- macOS 26.6.1 (25G76), Node 22.22.3, pnpm 9.15.0, Electron 41.7.0.
- No bb server, host daemon, provider, account, external page, port, or user data directory was used.
- The full monorepo build passed in the primary checkout; the dependency-aware desktop build passed in the verification checkout.
4. Minimal reproduction
- Clone trusted
get-bb/bband detach atd39bca3ebfa8e00ffcb9810b7d333a03f12c2bb0. - Install and build with:
pnpm install --frozen-lockfile --prefer-offline pnpm exec turbo run build
- 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); }); - 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
- #2929 reports the same embedded-browser signed-out behavior and already has a published reproduction report.
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.