feat(desktop): import browser cookies into a profile

[juliusmarminge]

Stacked on #7272 — review that first; this PR's base is shared-sqlite-client.

Imports cookies from a browser already installed on the machine into a T3 Code browser profile. Helium on macOS is the first source.

Cookies carry the logged-in sessions, which is what makes an imported profile useful. Saved passwords are deliberately out of scope — Electron exposes no password store to put them in, so importing them would mean building a credential vault and autofill injection.

The consent path is the design

The key is read through the in-process Keychain API, not by shelling out to /usr/bin/security. macOS attributes both the prompt and the resulting ACL grant to the binary that asks:

	prompt says	grant belongs to
security CLI	"security"	a tool any process can invoke
in-process	T3 Code	this app

There is no fallback when consent is denied. The techniques that work around it exist to defeat exactly this, and this feature isn't worth shipping them. unsupportedPlatform covers the case that isn't a permission at all — Chrome on Windows, whose App-Bound Encryption is designed to stop this.

The read is untimed: macOS answers it with a modal, and a timeout racing the user means the prompt can be approved after nothing is left listening — which reads as "approving did nothing".

Notes for review

Sources pin their own coordinates. Chromium forks disagree: Helium uses keychain service Helium Storage Key / account Helium, where Chrome and closer relatives use <Name> Safe Storage / <Name>.

expires_utc overflows JS safe integers — microseconds since 1601, which node:sqlite refuses to narrow. The division happens in SQL so only seconds cross the boundary. This affected nearly every cookie.

The cookie DB is snapshotted before reading, since Chromium keeps it open with WAL and reading in place can observe a torn write.

Packaging: the platform .node is staged beside the loader, mirroring the existing Clerk passkey handling — pnpm nests the arch package, electron-builder only retains top-level deps, and the napi loader checks for a sibling binary first. Without this it works in dev and fails when packaged.

Failures are differentiated rather than collapsed into "approve the prompt", which is useless advice for a missing keychain item.

Testing

Typecheck and lint clean; suite passing. Verified end to end in the desktop app against a real Helium profile: 5,002 cookies imported, 26 skipped, with the prompt correctly naming T3 Code.

The decrypt path can't be unit-tested — it requires a Keychain prompt to be answered — so it is exercised in the app rather than in CI.

Note

Add browser cookie import wizard to desktop profile settings

• Adds a multi-step import wizard (BrowserImportWizard.tsx) guiding users through importing cookies from Chromium-family browsers into a new or existing profile, with steps for quit prompt, source/target selection, progress, success summary, and error handling.
• Implements a new BrowserImport desktop service (BrowserImport.ts) that lists available browser sources and imports cookies via readChromiumCookies, writing them into the target Electron session partition.
• Reads Chromium cookies on macOS by snapshotting the SQLite DB (including WAL sidecars), decrypting values via OSCrypt/AES-128-CBC using the macOS keychain password (ChromiumCookies.ts).
• Exposes two new IPC endpoints (PREVIEW_IMPORT_SOURCES_CHANNEL and PREVIEW_IMPORT_COOKIES_CHANNEL) wired through preload, main process handlers, and the DesktopPreviewBridge contract.
• Replaces the standalone default-profile selector in Integrations settings with per-row actions (set default, clear cookies/cache, remove, import), and removes the browser-default-profile search entry.
• Stages @napi-rs/keyring native binaries during desktop artifact builds to satisfy sibling-first resolution.
• Risk: cookie import is macOS-only; non-darwin platforms receive a unsupportedPlatform error. Profile directory inputs are hardened against path traversal via isSafeProfileDirectory.

^{Macroscope summarized 2d762e5.}

---

Note

High Risk
Reads and decrypts another app’s cookie database via Keychain and writes into Electron partitions; security-sensitive despite path/profile validation and explicit non-bypass of consent.

Overview
Adds cookie import from installed Chromium-family browsers (first source: Helium on macOS) into T3 Code preview profile partitions, wired through new contracts, desktop BrowserImport / ChromiumCookies services, and IPC (listBrowserImportSources, importBrowserCookies) exposed on the preload bridge.

On macOS the flow reads the browser’s SQLite cookie store (with a WAL snapshot), decrypts v10 values using the OS keychain via in-process @napi-rs/keyring (no security CLI fallback), validates source profiles to block path traversal, refuses import while SingletonLock indicates the browser is running, then writes cookies into the target Electron session with host-only vs domain-cookie handling. Packaging stages keyring .node binaries like existing Clerk passkey natives.

Integrations → Browser profiles gains an Add profile menu (blank profile or import from a detected browser), a multi-step BrowserImportWizard, per-row ⋮ actions (set default, clear data, remove), and Default badges; the separate default-profile selector and its settings-search entry are removed. New profiles from import are persisted only when imported > 0.

Unit tests cover source detection/hardening, wizard step logic, and cookieScope; keychain decrypt is exercised manually per PR notes. BrowserImportWizard still has a TEMP layout comment to clean up before merge.

^{Reviewed by Cursor Bugbot for commit 2d762e5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 206eb18f-5030-4953-a326-6ae45cca16a6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	12.6 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.3 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	51.8 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	16	—	21	✅
Claude	Total thread wire	—	12.6 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.3 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	52.7 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	16	—	21	✅

Baseline: unavailable · PR result: 40385ef · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 99.9 KiB
• Claude decoded thread snapshot: 100.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Needs human review

4 blocking correctness issues found. New feature introducing browser cookie import capability, touching keychain APIs and external browser data. Contains an unresolved HIGH severity finding about symlinked profile directories potentially allowing reads outside intended paths, plus multiple race condition concerns in the UI layer.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

🟡 Medium settings/IntegrationsSettings.tsx:786

Per-profile actions remain usable while busy is true, so a user can remove a profile during an in-flight import; removeProfile clears its partition, but the import can then write cookies back into that orphaned partition. Disable the profile action trigger and menu items while the import is running.

-                      disabled={disabled}
+                      disabled={disabled || busy}
@@
-                    disabled={isDefault}
+                    disabled={busy || isDefault}
@@
-                  <MenuItem onClick={() => clearProfileData(profile.id, profile.name)}>
+                  <MenuItem disabled={busy} onClick={() => clearProfileData(profile.id, profile.name)}>
@@
-                      onClick={() => setProfilePendingRemoval(profile)}
+                      disabled={busy}
+                      onClick={() => setProfilePendingRemoval(profile)}

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/settings/IntegrationsSettings.tsx around lines 786-809:

Per-profile actions remain usable while `busy` is `true`, so a user can remove a profile during an in-flight import; `removeProfile` clears its partition, but the import can then write cookies back into that orphaned partition. Disable the profile action trigger and menu items while the import is running.

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

🟡 Medium BrowserImport/BrowserImport.ts:200

Cancelling the import fiber is converted to false here, so a shutdown or other interruption does not stop the loop and it continues attempting every remaining session.cookies.set write. Effect.catchCause handles interruption as well as promise failures; catch only the typed failure channel so interruption propagates.

Suggested change

	Effect.catchCause(() => Effect.succeed(false)),
	Effect.catch(() => Effect.succeed(false)),

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/desktop/src/preview/BrowserImport/BrowserImport.ts around line 200:

Cancelling the import fiber is converted to `false` here, so a shutdown or other interruption does not stop the loop and it continues attempting every remaining `session.cookies.set` write. `Effect.catchCause` handles interruption as well as promise failures; catch only the typed failure channel so interruption propagates.

[macroscopeapp]

🟠 High BrowserImport/Sources.ts:105

A symlinked profile such as <userData>/Default lets cookieDatabasePath resolve and import <external>/Cookies outside the browser user-data directory. isSafeProfileDirectory only validates the key lexically, so it does not enforce the path-containment guarantee described here; resolve the profile path and verify it remains under root (or reject symlinked profile components) before returning it.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/desktop/src/preview/BrowserImport/Sources.ts around line 105:

A symlinked profile such as `<userData>/Default` lets `cookieDatabasePath` resolve and import `<external>/Cookies` outside the browser user-data directory. `isSafeProfileDirectory` only validates the key lexically, so it does not enforce the path-containment guarantee described here; resolve the profile path and verify it remains under `root` (or reject symlinked profile components) before returning it.

[macroscopeapp]

One finding: the new profile badge in the preview chrome row uses a native title tooltip where every other hover hint in that row goes through the shared Tooltip primitive.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

UI consistency review of the new browser-import surfaces. Three findings in apps/web/src/components/settings/BrowserImportWizard.tsx; the earlier findings in IntegrationsSettings.tsx (default-badge dimming, Clear cookies and cache silent no-op, default resolution against the rendered list) all look addressed at this head.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

ImportingStep renders a bare DialogPanel, so while it is on screen the popup has no DialogTitle. Base UI derives the dialog's accessible name from that title, so the dialog goes unnamed for assistive tech mid-flow, and visually the popup collapses to a spinner-only box between the configure and done screens. Every other step here supplies a header.

Suggested change

	function ImportingStep() {
	return (
	<DialogPanel className="flex items-center gap-3 py-6">
	<Spinner className="size-4 text-muted-foreground" />
	<span className="text-sm text-muted-foreground">Importing cookies…</span>
	</DialogPanel>
	);
	function ImportingStep() {
	return (
	<>
	<DialogHeader>
	<DialogTitle>Importing cookies…</DialogTitle>
	</DialogHeader>
	<DialogPanel className="flex items-center gap-3 py-6">
	<Spinner className="size-4 text-muted-foreground" />
	<span className="text-sm text-muted-foreground">This can take a moment.</span>
	</DialogPanel>
	</>
	);
	}

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Re-checking after the user quits the browser reuses the importing step, so the dialog shows the spinner labelled Importing cookies… while nothing is being imported — the import only starts later, from the configure screen. The same screen then means two different things depending on how it was reached.

Consider tracking which action is pending (re-check vs. import) and passing the label into ImportingStep, or adding a distinct checking step in browserImportWizard.logic.ts, so the busy copy matches the work in flight.

^{Posted via Macroscope — UI Consistency}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{Bugbot Autofix is ON, but a cloud agent failed to start.}

^{Reviewed by Cursor Bugbot for commit 05fe2c1. Configure here.}

[macroscopeapp]

Two findings in the import wizard's changed lines. Earlier findings on this PR (the importing step doing double duty for the post-quit re-check, and ImportingStep rendering without a DialogTitle) are still open but not re-posted here.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

This TEMP note describes an in-dialog layout switcher that no longer exists and asks for its removal before merge, so it now misdescribes ConfigureStep for anyone reading the file. Worth dropping it (and folding the single-consumer ConfigureFooter extraction back into ConfigureStep, since it was only shared between the switcher's variants).

Suggested change

	// TEMP: an in-dialog layout switcher for comparing directions live — the ui.sh
	// picker can't load under the app's CSP. Collapse to the chosen variant and
	// delete this switcher before merge.
	function ConfigureStep({
	function ConfigureStep({

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

SelectableTile is the wizard's only selection control, but the raw <button> exposes its state visually only — no aria-pressed/aria-checked, so assistive tech reads the two mutually exclusive lists as plain buttons and never announces which profile is picked. Every comparable custom tile in the repo carries that state (ConnectionsSettings connection-mode cards use aria-pressed, its endpoint tiles use role="radio"/aria-checked inside a labelled role="radiogroup"), and those also add a focus-visible ring since the tile opts out of the Button primitive's ring.

Smallest fix is to expose the pressed state and restore the ring here; if you want full radio semantics instead, wrap each <section> in role="radiogroup" with an aria-label and switch to role="radio"/aria-checked.

Suggested change

	<button
	type="button"
	onClick={onSelect}
	className={cn(
	"flex w-full items-center justify-between gap-3 rounded-lg border px-3 py-2 text-left transition-colors",
	selected
	? "border-primary bg-primary/8"
	: "border-border/60 hover:border-border hover:bg-muted/40",
	)}
	>
	<button
	type="button"
	aria-pressed={selected}
	onClick={onSelect}
	className={cn(
	"flex w-full items-center justify-between gap-3 rounded-lg border px-3 py-2 text-left outline-none transition-colors focus-visible:ring-2 focus-visible:ring-ring",
	selected
	? "border-primary bg-primary/8"
	: "border-border/60 hover:border-border hover:bg-muted/40",
	)}
	>

^{Posted via Macroscope — UI Consistency}