In-app browser opens signed-in services on their login form #3059

What happens now

A thread's answer links to a Google Doc, a Notion page or a Figma file. Clicking it opens the in-app browser on a sign-in form instead of the document, because the browser view runs on its own persist:bb-browser Electron session while the person is signed in through their normal browser.

Signing in inside that tab is not a way out: Google refuses sign-in from an embedded browser (disallowed_useragent), so the session stays empty no matter how many times the tab is opened.

The only workaround left is to divert every link on those services to the default browser, which takes the artefact out of bb — exactly the thing the in-app browser exists to avoid.

What I would expect

Opening an artefact from a thread lands in the in-app browser, signed in, the same as any other tab in the app.

Prototype

Working in a fork (signed-in-session.ts, branch feature/thread-project-dnd-and-panes), two pieces are enough:

1. User agent. session.fromPartition(partition) keeps the default string, which names both Electron/ and bb/. Dropping those two segments in ensureHardenedSession is what makes services serve their real page rather than a degraded or refused one. This alone is a small, self-contained improvement.

2. Carrying the existing sign-in. The desktop shell reads the cookies of a fixed list of hosts (google.com, googleusercontent.com, notion.so, figma.com, miro.com, fireflies.ai) from the Chrome profile on the same machine and writes them into the browser session before a tab on one of those hosts loads, refreshing at most every ten minutes because Google rotates them during the day. Only those hosts are read; the rest of the cookie jar is none of the app's business.

Two details that cost time and are easy to get wrong:

• Chrome 127+ prefixes the decrypted value with sha256(host_key). Recognising the prefix by that digest matters: a cookie whose value genuinely starts with 32 characters would otherwise be truncated and carry a session that fails much later, in a way that looks like a server problem.
• Reading the live Cookies database returns "database is locked" often enough to look like "no cookies"; a copy reads reliably.

Happy to open a PR if the direction is welcome, and to discuss whether the carry-over should be opt-in in settings rather than automatic.