#4235 · Desktop Connect cookie session mismatch

Bug · Priority: Medium · Effort: Medium · remote, desktop, connect

Issue · 2026-09-24 · base 9bfe862b3506f5b220f627af3513797152a2b39d

PARTIALLY REPRODUCED · Root-cause confidence: medium

1. TL;DR

Desktop authentication populates Electron's default cookie store, while the personal Browser uses a separate partition. A focused harness executed the current installer and confirmed that it can return success after writing only one store. This supports a missing-session mechanism, but does not establish the reported difference between clicking and pasting a URL. Full desktop navigation was not run because the local pnpm executable is broken.

2. Claims vs findings

3. Environment

Public repository get-bb/bb; main SHA above matched both origin/main and GitHub's main endpoint. macOS 26.6.2, Node v22.22.3; desktop manifest 0.43.4, Electron dependency 44.3.0. No Electron process, provider, network server, port, real credential, or runtime data directory was used. Both temporary worktrees were clean before and after the harness.

4. Minimal reproduction

This is a partial mechanism check with synthetic in-memory cookie stores, not an Electron integration test. It extracts the trusted installer and helper functions without modifying them, strips TypeScript with Node, and executes them. Source assertions check the session wiring. The separate-store array models isolation; it does not prove Electron's cookie behavior.

1. Fetch trusted main and create a detached checkout at the recorded SHA.
2. Download check.mjs.
3. Run node --disable-warning=ExperimentalWarning check.mjs /path/to/checkout using Node 22.22.3.

Expected for the desired product behavior: personal Browser also receives authentication. Actual limited harness result:

Installer result: ok=true
Default store cookies: 1
Separate Browser store cookies: 0
PASS: single-store installation mechanism confirmed; real Electron navigation untested

The harness passes by asserting the observed missing-store mechanism; it is not a red/green production regression test.

import { readFileSync } from 'node:fs';
import { stripTypeScriptTypes } from 'node:module';
import vm from 'node:vm';
import assert from 'node:assert/strict';
const root = process.argv[2];
const read = path => readFileSync(`${root}/apps/desktop/src/${path}`, 'utf8');
const main = read('main.ts');
const browser = read('desktop-browser-view.ts');
assert.match(main, /const cookieStore = session\.defaultSession\.cookies;/);
assert.match(browser, /const BB_BROWSER_PARTITION = "persist:bb-browser"/);
assert.match(browser, /session\.fromPartition\(tabPartition\)/);
const source = read('connect-desktop-session.ts');
const helpers = source.slice(source.indexOf('function failure('), source.indexOf('export function createLocalServerCookieSource'));
const installer = source.slice(source.indexOf('export async function installConnectDesktopSession')).replace('export ', '');
const js = stripTypeScriptTypes(helpers + installer);
const install = vm.runInNewContext(js + '\ninstallConnectDesktopSession', { URL });
const defaultCookies = [];
const browserCookies = [];
const store = {
  async set(cookie) { defaultCookies.push(cookie); },
  async get() { return defaultCookies; },
};
const result = await install({
  cookieStore: store,
  mintCookie: async () => ({ ok: true, cookie: { domain: '.example.test', expiresAt: 2000000000000, name: 'test-session', value: 'synthetic-test-value' } }),
  remoteServerUrl: 'https://machine.example.test',
});
assert.equal(result.ok, true);
assert.equal(defaultCookies.length, 1);
assert.equal(browserCookies.length, 0);
console.log('Installer result: ok=true');
console.log('Default store cookies: 1');
console.log('Separate Browser store cookies: 0');
console.log('PASS: single-store installation mechanism confirmed; real Electron navigation untested');

5. Root cause

Authentication selects the default session:

const cookieStore = session.defaultSession.cookies;

Installer writes and verifies only args.cookieStore. It has no second-store target. The Browser partition constant is persist:bb-browser; personal profile selection and session creation use that isolated partition. Thus successful desktop authentication need not authenticate personal Browser requests. Additional navigation evidence is needed to explain the claimed paste workaround.

6. Proposed fix

Review intentional propagation of the minted cookie to the personal Browser session, including verification and failure handling. Keep automation profiles isolated. Test real Electron click and paste navigations against a controlled Connect gate with fresh profiles. No fix is submitted: authentication changes are explicitly excluded by the simple-fix rule, and the complete symptom remains unverified.

7. PR review

Open PR #4132, head 9c1db5c6eaf21c3812ed1025394abc99a48936e8, discovered via GitHub search, changes three desktop files. Static diff passes the personal session into the installer and writes/verifies each supplied store. This addresses the source mechanism. The manager-null branch in main.ts still supplies no additional store; startup-order coverage is needed before asserting complete coverage. The added test covers a successful additional-store install, not actual Electron navigation or manager initialization timing. Verdict: plausible mechanism fix; runtime efficacy unverified. No PR branch or test was run. GitHub closing-issue metadata did not link it to #4235.

8. Related issues

A repository search for Connect Browser authentication returned other broad matches; no duplicate conclusion was drawn. #4132 is an overlapping open implementation, not a newly created PR.

9. Verification

The same agent repeated the identical harness in a second clean detached checkout named verify at the same SHA. Both runs returned the same four lines and exit code 0. No ports or data directories were needed. First output · Second output. Verification supports only the partial verdict and mechanism, not independent validation or the user-visible click/paste distinction. No correction between runs was necessary.

10. Appendix

Normal frozen install was attempted with pnpm install --frozen-lockfile --prefer-offline; normal build was attempted with pnpm exec turbo run build --filter=@bb/desktop. Both failed before execution with MODULE_NOT_FOUND for the pnpm 10.34.4 entrypoint. Dependencies were not added and the environment was not repaired. The dependency-free Node harness was used as a deliberate diagnostic fallback. No screenshot is included because no visual interaction was observed.

Read-only investigation used git fetch, git show, git worktree add, git status, GitHub issue properties and labels, issue searches, PR metadata and diff, node --version and sw_vers. Untrusted issue text and PR diff were treated only as evidence; no instructions or code from them were executed. No application processes required cleanup.