feat(desktop): import from Chrome, Edge, Brave, Vivaldi, Opera, Arc and Firefox

[juliusmarminge]

Stacked on #7255 — review that first; this PR's base is browser-profile-import.

Generalises the importer from one hardcoded browser to a source registry with two engines, taking it from 1 source to 8.

Source	Engine	macOS	Windows	Linux
Chrome, Edge, Brave, Vivaldi, Opera	chromium	✅	paths only¹	paths only¹
Arc, Helium	chromium	✅	—	—
Firefox	firefox	✅	✅	✅

¹ Chromium off macOS reports unsupportedPlatform until its key stores land — that's the next PR.

Notes for review

Chromium forks are table entries. They share the existing extractor and differ only in paths and keychain coordinates. Those are pinned per fork rather than derived, because the forks disagree — Helium uses Helium Storage Key / Helium where the others use <Name> Safe Storage / <Name>.

Firefox is a second engine with no crypto at all. It stores cookies in plaintext cookies.sqlite, so there's no key and no consent prompt. That's Mozilla's design choice, not a control being circumvented, and it's why Firefox works identically on all three platforms while Chromium needs a per-platform credential store.

Paths resolve from an injected context, not process, so Windows and Linux layouts can be checked without running on them.

The snapshot-before-read step moved to a shared module. Both engines keep the database open with WAL, and neither may have the browser's own file opened for writing.

Testing

Verified against the machine this was written on — all seven Chromium sources detected, Chrome reporting its real profile name:

chrome  installed=true  profiles=Your Chrome
helium  installed=true  profiles=You
…

Firefox isn't installed here, so it's covered by tests against a real moz_cookies fixture rather than a claim — including one asserting the source file's mtime and size are unchanged after a read.

profiles.ini parsing has its own tests because of a genuine trap: Install* sections name a default profile without describing one, so counting them invents a directory that doesn't exist.

Note

Add browser import support for Chrome, Edge, Brave, Vivaldi, Opera, Arc, and Firefox

• Expands BROWSER_IMPORT_SOURCES in Sources.ts to include multiple Chromium-based browsers and Firefox, with per-platform user-data directory resolution.
• Introduces Firefox cookie import via FirefoxCookies.ts, reading from cookies.sqlite using NodeSqliteClient, restricted to the default container, with sameSite and session cookie mapping.
• Extracts shared helpers (cookieScope, bareHost, snapshotCookieDatabase, ImportedCookie) into CookieDatabase.ts for reuse across Chromium and Firefox paths.
• Adds BrowserImportPathContext to carry platform, home, appData, and localAppData for cross-platform path resolution; Chromium sources are now gated to macOS.
• Expands the contract in browserImport.ts to include all new source IDs.
• Risk: Chromium import is restricted to macOS; non-macOS platforms will receive unsupportedPlatform for all Chromium-engine sources.

^{Macroscope summarized f17e123.}

---

Note

Medium Risk
Touches cookie decryption, keychain access, and filesystem reads of other browsers’ profiles; path traversal hardening and lock checks are intentional, but wrong paths or lock logic could block imports or read stale DBs.

Overview
Generalises desktop browser cookie import from one hardcoded Chromium source to a registry of eight browsers (Chrome, Edge, Brave, Vivaldi, Opera, Arc, Helium, Firefox), modelled as chromium vs firefox engines with per-fork paths and keychain coordinates in Sources.ts.

BrowserImport now resolves paths via sourcePathContext / BrowserImportPathContext (platform, %APPDATA%, %LOCALAPPDATA%), lists profiles per engine (Chromium Local State vs Firefox profiles.ini), and dispatches reads to readChromiumCookies or readFirefoxCookies. Chromium import is rejected off macOS with unsupportedPlatform until non-macOS key stores exist; Firefox works on all platforms (plaintext DB, no keychain).

New FirefoxCookies maps moz_cookies to Electron’s cookie shape, snapshots before read, and imports only the default container (originAttributes = ''). Shared CookieDatabase holds ImportedCookie, cookieScope, and snapshotCookieDatabase (WAL/SHM copy semantics) used by both engines.

Source detection fixes: Firefox running checks profile-level locks (.parentlock, etc.) instead of Chromium’s root SingletonLock; Opera on Windows uses roaming AppData without a User Data segment. Contracts BROWSER_IMPORT_SOURCE_IDS grows to match the registry.

^{Reviewed by Cursor Bugbot for commit f17e123. 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: 4e898ff6-7d0c-4afc-b5ff-b8228c0c7749

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.}

[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: 533438c · 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]

One convention finding: the new Firefox cookie read path models its failure as an anonymous object literal instead of a Schema.TaggedErrorClass. Details inline.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

1 blocking correctness issue found. Substantial new feature adding cookie import from 7 browsers with significant new logic and security-sensitive file operations. An unresolved HIGH severity finding identifies a path traversal vulnerability in Firefox profile parsing that could allow importing attacker-controlled SQLite files.

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

[macroscopeapp]

Effect service conventions: one finding on the new FirefoxCookieReadError. The tagged-error union fix from the previous round looks good; what remains is the structural context the error captures.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One retained finding in the Firefox error model; the rest of the Effect service conventions look satisfied (namespace subpath imports, tagged errors at the failure boundary, Context.Service/make/layer order preserved, no new runtimes or injected service instances).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the mapped error union is discriminated by hand instead of with Effect.catchTags.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🟠 High BrowserImport/Sources.ts:232

listSourceProfiles returns Path=../../... and arbitrary absolute paths from profiles.ini as trusted profile directories, so cookieDatabasePath can open <that path>/cookies.sqlite outside Firefox’s user-data directory and import an attacker-selected SQLite file. Validate and normalize each parsed path before returning it, enforcing the intended Firefox profile-root boundary (while explicitly handling any supported legitimate absolute-profile case).

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

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

`listSourceProfiles` returns `Path=../../...` and arbitrary absolute paths from `profiles.ini` as trusted profile directories, so `cookieDatabasePath` can open `<that path>/cookies.sqlite` outside Firefox’s user-data directory and import an attacker-selected SQLite file. Validate and normalize each parsed path before returning it, enforcing the intended Firefox profile-root boundary (while explicitly handling any supported legitimate absolute-profile case).

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

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

^{Reviewed by Cursor Bugbot for commit 18520a8. Configure here.}