Uh oh!
There was an error while loading. Please reload this page.
feat(desktop): import from Chrome, Edge, Brave, Vivaldi, Opera, Arc and Firefox - #7260
feat(desktop): import from Chrome, Edge, Brave, Vivaldi, Opera, Arc and Firefox#7260juliusmarminge wants to merge 22 commits into
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
Uh oh!
There was an error while loading. Please reload this page.
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: unavailable · PR result: Scenario and decoded snapshot size10 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.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
bc1215b to
973b17eCompareThere was a problem hiding this comment.
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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
ApprovabilityVerdict: Not approved Macroscope's review found this PR not approvable — This PR adds a multi-browser cookie-import capability with new cross-platform discovery, database extraction, lock handling, Keychain interaction, and session-cookie writes. It also introduces a static-analysis diagnostic suppression in a new test, so the scope and sensitive-data handling warrant human review. No code changes detected at You can add or adjust custom eligibility rules. Learn more. |
973b17e to
1b132e4CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
3343565 to
56f1705CompareThere was a problem hiding this comment.
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
Uh oh!
There was an error while loading. Please reload this page.
56f1705 to
4d48bd9Compare4d48bd9 to
0d85caaCompareUh oh!
There was an error while loading. Please reload this page.
7a8cf25 to
27037c9CompareUh oh!
There was an error while loading. Please reload this page.
27037c9 to
9328514CompareUh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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 8360b0f. Configure here.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…Firefox Generalises the importer from one hardcoded browser to a source registry with two engines. Chromium forks are table entries: Chrome, Edge, Brave, Vivaldi, Opera, Arc and Helium all share the existing extractor and differ only in their paths and keychain coordinates. Those coordinates 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. It stores cookies unencrypted in `cookies.sqlite`, so there is no key to fetch and no consent prompt — that is Mozilla's design choice, not a control being circumvented, and it is why Firefox works identically on all three platforms while Chromium still needs a per-platform credential store. Paths resolve for macOS, Windows and Linux from an injected context rather than from `process`, so a platform's layout can be checked without running on it. Chromium off macOS still reports `unsupportedPlatform` until those key stores land; Firefox does not. The snapshot-before-read step moves to a shared module, since both engines keep the database open with WAL and must never have the browser's own file opened for writing. Firefox has tests against a real `moz_cookies` fixture, including that the source file is left untouched, and `profiles.ini` parsing covers the `Install*` sections that name a default profile without describing one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Firefox keeps its lock files inside each profile, not at the user-data root, so the running check never found them and offered imports from a live, mid-write database. It now walks the source's profiles and looks for all three names the platforms use. Firefox isolates cookies per container and per private window through `originAttributes`. Electron has no equivalent, so importing them all collapsed several identities onto one host/name/path and handed the profile whichever container was written last. Only the default container is imported. The sidecar copy no longer ignores every error alongside the missing-file case; the new snapshot test caught that the earlier fix had landed on the pre-extraction copy of this code rather than the shared module. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Firefox branch failed with an anonymous `{ reason, cause }` literal, and
typing the shared `read` value as that shape erased `ChromiumCookieReadError`'s
tag from the error channel — neither branch could then be handled with
`Effect.catchTags`.
`FirefoxCookieReadError` mirrors its Chromium counterpart, so the union stays
structurally identifiable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>Firefox keeps one cookie database per profile, so a failure carrying only a reason cannot be traced back to the profile that produced it. The path is now a structural attribute, matching `ChromiumCookieReadError`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Firefox has one failure mode — its plaintext database would not open — so a single-value `reason` literal encoded the same thing as the tag, and `cause` was optional though every construction site wraps a real failure. The error now carries the database path and a required cause, and `BrowserImport` supplies the user-facing reason where it maps the union. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The union was discriminated with a `cause._tag` ternary inside `Effect.mapError` even though both members are statically known tagged errors; `Effect.catchTags` says the same thing without the manual check. The comment above `read` claiming both carry a `reason` was stale — Firefox's no longer does. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Firefox schema 16 (Firefox 129) moved `moz_cookies.expiry` from seconds to milliseconds — the migration is `UPDATE moz_cookies SET expiry = expiry * 1000` — but the reader passed the value straight through as seconds, so persistent cookies from a current Firefox were imported ~1000× too far in the future. Older profiles still hold seconds, so the unit is decided by `PRAGMA user_version` rather than assumed either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… browser `isSourceRunning` treated `.parentlock` / `parent.lock` as proof Firefox held the profile, but Firefox deliberately leaves those on disk after a clean exit (as a last-used marker) and only releases the OS-level fcntl or handle lock — so once Firefox had been used, the source reported `browserRunning` forever and cookie import never proceeded. Verified against Firefox's nsProfileLock.cpp: only the Linux `lock` symlink (target `<ip>:[+]<pid>`) is unlinked on exit, so its presence plus a live pid is the POSIX signal; a dead pid means a crash. Node has no fcntl probe, so `.parentlock` carries no signal on POSIX. On Windows the held handle denies our open as `Busy`, which is the signal there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…s detected Follow-ups to the leftover-lock fix. On macOS a running Firefox writes nothing but an empty `.parentlock` held with an fcntl lock — no symlink, no pid — so reading only the Linux `lock` symlink missed it entirely and offered imports from a live, mid-write database. Node exposes no fcntl, so a throwaway `python3` child tries a non-blocking F_SETLK and reports whether it blocks; any failure to get a clean answer counts as held, so a probe problem can never unlock a live profile. The Linux symlink still short-circuits first. The symlink's owner half is honoured too: a non-loopback address is a shared profile locked from another machine, whose pid cannot be probed here, so it stays held. Also drops a Safari paragraph from `entryExists`' doc that described `databaseFileExists`' concern, not this helper's. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… Windows lock probe A Firefox import logged "Reading browser cookie key from the keychain" with the executable path even though it never touches a keychain, putting a false security-sensitive event in the audit trail; the log now sits behind the Chromium engine check. Also narrows isLockHeld to the Windows probe its doc describes (its only caller already guards on win32) and deletes entryExists, which that dead branch was the last use of. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ock symlink The owner check treated only 127.0.0.1 and ::1 as ours, but Firefox writes whatever its resolver returns for the machine's hostname — 127.0.1.1 on Debian-style hosts, a LAN address elsewhere, loopback only when the lookup fails. A crashed Firefox on such a host left a symlink the check read as foreign and held forever, blocking import. The owner is now matched against every address the machine answers to, via a new `HostProcessAddresses` reference that mirrors `HostProcessHostname` and is injectable in tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…name-resolved addresses as local Two follow-ups on the Firefox lock detection. A Dock-launched app has launchd's bare PATH, so `python3` could go unfound; the probe now names `/usr/bin/python3` absolutely first. More importantly, "held" is now only ever the script's own verdict: a probe that never ran — no interpreter, or Apple's shim on a Mac without the developer tools, which exits non-zero after prompting to install — is the probe being unavailable, not evidence about the lock, and falls back to "not held" rather than blocking Firefox import on that machine for good. The SQLite snapshot copes with a live WAL as it does for every other engine. And `HostProcessAddresses` collected only interface addresses, so a hostname mapped in /etc/hosts to an address no interface carries — Debian's 127.0.1.1 — read as foreign, holding a crashed Firefox's lock forever. The set now also includes what the resolver returns for the machine's hostname, which is exactly what Firefox writes into the lock. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Firefox stores nsICookie::SAMESITE_UNSET (256) for a cookie that carried no SameSite attribute, distinct from SAMESITE_NONE (0), an explicit opt-in to cross-site use. The reader collapsed the unknown value onto Lax, and the reviewed suggestion would have made it None — both change the cookie's meaning. `ImportedCookie` now carries Electron's own `unspecified`, which lets the target browser apply its default exactly as the source did, and both engines map their "no attribute" sentinel (Firefox 256, Chromium -1) to it. Also drops a doubled `/**` opener left above `cookieDatabaseCandidatePaths`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Rows from before schema 9 hold NULL in sameSite, which failed decoding and aborted the whole import. Schemas 10-14 also keep the declared value in rawSameSite beside a Lax default; apply Firefox's own schema-15 migration rule so an undeclared cookie imports as unspecified rather than as an explicit Lax.
The hostname DNS lookup ran once per profile and even on Windows, where the symlink lock that needs it never exists.

Stacked on #7255 (
browser-profile-import).Expands cookie import to a source registry with Chromium and Firefox readers.
Firefox imports its default container; other containers are excluded so their sessions are not mixed. Discovery respects
profiles.ini, validates relative paths, supports explicitly configured absolute profile directories, and ignores fallback entries without a cookie database. Counts use the same default-container filter as the reader.Both engines share a consistent read-only SQLite snapshot path. Windows Chromium remains intentionally unsupported, preserving the Windows-tested contribution #7323.
Validation: focused source-discovery, path-validation, Firefox cookie/count, and SQLite snapshot fixtures. Cross-platform path tests run on macOS; they are not a substitute for another live Windows/Linux test.
Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.
Note
Add Chrome, Edge, Brave, Vivaldi, Opera, Arc, and Firefox import to desktop
BROWSER_IMPORT_SOURCESregistry to include Chrome, Edge, Brave, Vivaldi, Opera, Arc, and Firefox, using a platform-awareBrowserImportPathContextto resolve user-data directories.profiles.ini, handles schema-specific expiry and SameSite conversions, filters to default-container cookies, and uses Windows or POSIX lock probes to detect if the browser is running.CookieDatabase.tsfor use by both Chromium and Firefox engines.profileLimitReachedfailure reason andProfileLimitReachedErrorwhen profile creation or import persistence exceeds the configured maximum.BrowserImport.unavailableReason; out-of-tree consumers will receiveunsupportedPlatforminstead of attempting unsupported keychain reads.Macroscope summarized ff29cce.
Note
Medium Risk
Touches cookie/session import, filesystem path validation, and keychain reads on macOS; Firefox lock probing spawns Python and may allow import while Firefox is running if the probe is unavailable.
Overview
Adds a multi-browser import registry (Chrome, Edge, Brave, Vivaldi, Opera, Arc, Helium, Firefox) with an
enginesplit andBrowserImportPathContext(platform, home, Windows%APPDATA%) replacing the oldsourcePathshelper.Firefox gets a plaintext
cookies.sqlitereader,profiles.inidiscovery with path hardening, default-container-only imports, schema-aware expiry/SameSite handling, and per-profile running detection (Linuxlocksymlinks, macOS.parentlockfcntl via a short Python probe, Windowsparent.lock).HostProcessAddressesresolves local IPs for lock ownership checks.Chromium sources share a
chromiumSourcefactory (macOS + Linux paths; non-macOS Chromium import is gated asunsupportedPlatformuntil other key stores exist). SharedCookieDatabaseholdsImportedCookie, WAL-safesnapshotCookieDatabase, andcookieScope.BrowserImport.importCookiesbranches on engine, skips keychain audit logs for Firefox, and maps Chromium unspecified SameSite to Electronunspecifiedinstead of forcing Lax.Contracts expand
BROWSER_IMPORT_SOURCE_IDS; tests cover Firefox/Chromium readers, snapshots, locks, and discovery edge cases.Reviewed by Cursor Bugbot for commit ff29cce. Bugbot is set up for automated code reviews on this repo. Configure here.