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

🟠 High BrowserImport/Sources.ts:156

A running Firefox is reported as available, so cookie import proceeds while its database is being written and can produce readFailed or an inconsistent cookie set instead of browserRunning. isSourceRunning checks lock/parent.lock under the Firefox root, but Firefox creates them inside each profile directory returned by listSourceProfiles; check the profile directories before allowing import.

✅ Resolved in 1b132e45546ca54fb62fd0bde080ac4d3f656263

🟡 Medium BrowserImport/Sources.ts:138

Opera is never detected on Windows because windowsSegments resolves it to %LOCALAPPDATA%\Programs\Opera\User Data, while Opera stores profiles under %APPDATA%\Opera Software\Opera Stable (or Opera GX Stable). Update the Windows path resolution to use the roaming AppData locations.

✅ Resolved in 1b132e45546ca54fb62fd0bde080ac4d3f656263

🟡 Medium BrowserImport/FirefoxCookies.ts:53

Firefox cookies from different containers with the same host, name, and path overwrite one another during rows.map, so the imported profile receives an arbitrary container's session and mixes isolated browsing identities. The query omits originAttributes, so the importer cannot distinguish these rows; carry that attribute through extraction and define a collision policy for Electron, which has no equivalent container key.

✅ Resolved in 1b132e45546ca54fb62fd0bde080ac4d3f656263

🟡 Medium BrowserImport/CookieDatabase.ts:48

An existing -wal or -shm sidecar that fails to copy is silently ignored, so SQLite reads the snapshot without those transactions and the import can omit current cookies instead of failing. Effect.ignore suppresses permission and I/O errors as well as file-not-found; only suppress the expected missing-sidecar error.

✅ Resolved in 1b132e45546ca54fb62fd0bde080ac4d3f656263

Firefox running check misses locks

High Severity

isSourceRunning looks for Firefox lock / parent.lock under the Firefox user-data root, but those files live inside each profile directory (and on macOS/Linux the persistent file is .parentlock). A running Firefox therefore never reports browserRunning, so import can proceed against a live cookies.sqlite and observe torn WAL state or fail the read.

^{Reviewed by Cursor Bugbot for commit 973b17eae96dbcfe60139c81d6ee680b98933508. Configure here.}

Wrong Opera Windows data path

Low Severity

Opera on Windows is registered as %LOCALAPPDATA%\Programs\Opera\User Data, but stable Opera keeps its Chromium profile under %APPDATA%\Opera Software\Opera Stable (no trailing User Data). The shared chromiumSource helper always uses localAppData and appends User Data, so this layout cannot be expressed as written and will mis-resolve once non-macOS Chromium import is enabled.

^{Reviewed by Cursor Bugbot for commit 973b17eae96dbcfe60139c81d6ee680b98933508. Configure here.}

🟠 High BrowserImport/FirefoxCookies.ts:75

Host-only Firefox cookies are imported with domain: row.host, so Electron normalizes example.com to a domain cookie and exposes it to every subdomain. Omit domain when row.host has no leading dot (and update the cookie type if needed) to preserve the original scope.

✅ Resolved in 5f17f5b058ed672e12c08ce390038b23f18fe7a2

Firefox Linux path ignores XDG

High Severity

Firefox’s Linux userDataDirectory always resolves to ~/.mozilla/firefox. Since Firefox 147 (Jan 2026), fresh installs keep profiles.ini and profiles under $XDG_CONFIG_HOME/mozilla/firefox (usually ~/.config/mozilla/firefox) when the legacy tree is absent, so those installs are reported as notInstalled and never importable on Linux.

^{Reviewed by Cursor Bugbot for commit 33435655377e6cd6f406368baff28613d4c7308c. Configure here.}

BrowserImport/FirefoxCookies.ts:44

FirefoxCookieReadError ends up carrying no variable context: reason has a single literal value, so it only restates what the tag already says, and the cookieDatabasePath that is in scope at both wrapping sites is dropped — ChromiumCookieReadError keeps that field precisely so a user with several browsers can tell which read failed. cause is also optional even though every construction here wraps a real failure.

Consider dropping the singleton reason, adding a required cookieDatabasePath: Schema.String plus a required cause: Schema.Defect(), and deriving message from the path. BrowserImport.importCookies would then map the two engines with Effect.catchTags (supplying reason: "readFailed" for the Firefox tag) instead of reading cause.reason off the union.

No longer relevant as of 7a8cf253130c2b6b13101e72a3b6b113077ac98c

Wrong Chromium cookie database path

High Severity

cookieDatabasePath always joins the Chromium profile directory with Cookies, but current Chrome, Edge, Brave, Vivaldi, and Arc keep the live database under Network/Cookies. Helium (and possibly some Opera builds) still use the legacy root path, so a single hardcoded filename breaks import for the newly added mainstream forks—either as readFailed, or as a silent zero-cookie success if a stale empty root Cookies file remains.

^{Reviewed by Cursor Bugbot for commit 7a8cf253130c2b6b13101e72a3b6b113077ac98c. Configure here.}

BrowserImport/BrowserImport.ts:191

Both failures are statically known tagged errors, so the branch belongs in Effect.catchTags rather than a hand-rolled cause._tag ternary inside mapError. That also keeps each handler's reason next to the tag it applies to.

The comment above read ("Both branches fail with a tagged error carrying a reason") is now stale too — FirefoxCookieReadError deliberately has no reason.

No longer relevant as of 8538b6cede1f0d126bce980caf52b2dda2e9c359

Firefox fallback lists empty profiles

Low Severity

When profiles.ini is missing or unreadable, the Firefox fallback lists every entry under Profiles/ without checking for cookies.sqlite. The Chromium fallback only keeps directories that actually hold a cookie database, so Firefox can surface phantom profiles that later fail with readFailed.

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

Firefox lock files block all imports

High Severity

isSourceRunning treats existence of .parentlock or parent.lock as Firefox being open. Firefox leaves those files behind after quit so it can read last-used time; only the Unix lock symlink is removed. After a profile has been used once, listing and import both fail with browserRunning, so Firefox import cannot succeed.

^{Reviewed by Cursor Bugbot for commit 11c7e86a3d4d784ae486b9a3acc55acd577dc5f8. Configure here.}

🟡 Medium BrowserImport/Sources.ts:153

Firefox profiles returned from listSourceProfiles never receive a cookieCount, so the wizard shows an unknown count even when cookies.sqlite is readable. The declared-profile branch returns before calling withCookieCounts; pass those profiles through the same counting step used for Chromium.

Fixed in the updated #7260. Declared and fallback Firefox profiles receive cookie counts from moz_cookies filtered to originAttributes = empty string, matching the importer’s default-container policy. Unreadable schemas retain an unknown count. Fixtures cover all paths.

Linux Firefox path misses Snap installs

Medium Severity

Linux Firefox resolution only looks at ~/.mozilla/firefox. Default Ubuntu Snap profiles live under ~/snap/firefox/common/.mozilla/firefox (and Flatpak under ~/.var/app/org.mozilla.firefox/.mozilla/firefox), so the source is reported notInstalled on the most common Linux desktop even when Firefox is present.

^{Reviewed by Cursor Bugbot for commit 56220187d6f51dc4eb89e5772a328c4934314390. Configure here.}

🟠 High BrowserImport/Sources.ts:342

When profiles.ini is missing or malformed, the Firefox fallback presents every Profiles entry, including stale profiles and files, as selectable. Selecting one without cookies.sqlite then reaches readFirefoxCookies and fails instead of omitting the profile. Filter the fallback entries by checking for their cookies.sqlite database, as the Chromium fallback does.

🟠 High BrowserImport/FirefoxCookies.ts:75

readFirefoxCookies can fail or silently omit committed cookies when Firefox writes or checkpoints between the separate copies performed by snapshotCookieDatabase. Because the main database and -wal sidecar can come from different SQLite generations, the later read is not a consistent snapshot; use SQLite's backup/read-transaction facility (or otherwise hold a stable snapshot) instead of independent file copies.

🟠 High BrowserImport/Sources.ts:342

On Linux, the Firefox fallback returns no profiles even when cookies.sqlite exists, so isSourceInstalled reports Firefox as absent and the browser cannot be imported. The fallback always scans <root>/Profiles, but Linux profiles are direct children of <root>; scan <root> on Linux instead.

Fixed in the updated #7260. Linux Firefox fallback scans the root directory; macOS and Windows retain Profiles/. Fixtures cover the platform layouts and require cookies.sqlite.

This doc block described CookieReadResult, which moved to CookieDatabase.ts; it stayed behind and now reads as documentation for ChromiumCookieSource, which it does not describe. Consider deleting it here and folding the "count reaches the user as part of the skipped total" note into CookieReadResult's (currently one-line) comment in CookieDatabase.ts.

^{Posted via Macroscope — Effect Service Conventions}

🟠 High BrowserImport/Sources.ts:536

isSourceInstalled returns true for a Firefox profile whose cookies.sqlite is only a dangling symlink, so the source is shown as importable but selecting it later fails when the reader opens the missing target. Use a target-following stat check for Firefox databases while retaining entryExists for the Safari/TCC case.

Firefox lock files false-positive running

High Severity

isSourceRunning treats the presence of .parentlock or parent.lock as proof Firefox still holds the profile. Firefox leaves those files on disk after a clean exit and only releases the OS lock (fcntl/flock or a Windows handle). After Firefox has been used once, the source stays browserRunning and cookie import never proceeds.

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

Fixed in 1ce9a337af. Verified against Firefox's nsProfileLock.cpp: .parentlock/parent.lock are deliberately left on disk after a clean exit (as a last-used marker) and only the OS-level fcntl/handle lock is released, so their presence is not evidence. Only the Linux lock symlink (target <ip>:[+]<pid>) is unlinked on exit — that plus a live pid is now the POSIX signal, and a dead pid means a crash. Node exposes 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. Regression tests cover the stale-file, live-symlink, and crashed-pid cases.

🟠 High BrowserImport/FirefoxCookies.ts:108

Persistent Firefox cookies are imported with expiration timestamps about 1000× too far in the future because row.expiry is stored in milliseconds while Electron's expirationDate expects seconds. Convert row.expiry to seconds before assigning it.

Fixed in 5b13dd381e. Verified against Firefox's CookiePersistentStorage.cpp: schema 16 (Firefox 129) migrated expiry to milliseconds (UPDATE moz_cookies SET expiry = expiry * 1000), while older profiles still hold seconds — so the reader now reads PRAGMA user_version and divides only for schema ≥16, rather than assuming either unit. Regression test covers both a schema-16 and a schema-15 database.

🟠 High BrowserImport/Sources.ts:555

On macOS, firefoxProfileIsHeld returns false while Firefox is running, so unavailableReason allows importing a live, mid-write cookie database. The non-Windows branch only reads lock, but macOS uses .parentlock; handle the macOS lock marker in this branch.

isLockHeld's only caller guards on win32 (line 606), so the platform !== "win32" branch never runs — and it is the last remaining use of entryExists, whose documented rationale (the dangling Chromium SingletonLock and Firefox lock symlinks) no longer matches any caller either, since both probes now call readLink directly.

Consider narrowing this to the Windows probe its doc block describes — drop the platform parameter and the early return — and deleting entryExists along with it.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in ba690c491a. Narrowed to windowsLockIsHeld (no platform parameter, no dead POSIX branch) and deleted entryExists, which that branch was the last use of.

🟡 Medium

https://github.com/pingdotgg/t3code/blob/341268fce7fd31b07c92b124226c7e1323573cec/apps/desktop/src/preview/BrowserImport/BrowserImport.ts#L204

Every Firefox import logs Reading browser cookie key from the keychain and includes executablePath, even though Firefox uses readFirefoxCookies and never accesses a keychain. Move this log into the Chromium branch so support and audit logs do not report a false security-sensitive operation.

Local Firefox locks treated as foreign

Medium Severity

firefoxSymlinkLockIsHeld treats only 127.0.0.1 and ::1 as local owners. Firefox writes the IP it resolved for the machine hostname, which is often 127.0.1.1, 127.0.0.2, or a LAN address. A leftover lock symlink after a crash then stays held and blocks import.

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

Fixed in 8360b0f6ca. Verified against nsProfileLock.cpp: the address is whatever PR_GetHostByName returns for the hostname, falling back to 127.0.0.1 only when the lookup fails — so 127.0.1.1 and LAN addresses are routine. The owner is now matched against every address the machine answers to (new injectable HostProcessAddresses, mirroring HostProcessHostname), so a crashed Firefox on such a host no longer leaves a permanently-held lock. Tests cover loopback, 127.0.1.1, a LAN address, dead pids on each, and a genuinely foreign owner.

Hostname IPs treated as foreign locks

Medium Severity

HostProcessAddresses only collects addresses from os.networkInterfaces(), so Debian-style hostname IPs such as 127.0.1.1 never count as local. firefoxSymlinkLockIsHeld then treats that owner as foreign and reports the profile held without checking the pid, so a leftover lock symlink after a crash blocks Firefox import indefinitely.

^{Reviewed by Cursor Bugbot for commit 8360b0f6ca4aac215cbc9e119bf1601999f75205. Configure here.}

Fixed in 1f8e906e7f. HostProcessAddresses now unions the interface addresses with whatever the resolver returns for the machine's own hostname — which is exactly what Firefox writes into the lock — so a /etc/hosts mapping like 127.0.1.1 counts as local. It's an Effect now (the lookup is async), still injectable for tests.

macOS Firefox import needs python3

High Severity

macOS Firefox running detection always probes .parentlock with a python3 child. That file is left on disk after a clean exit, and any probe failure — including a missing interpreter — counts as held. Packaged apps launched from the Dock rarely have python3 on PATH, so Firefox import stays blocked after the browser has been used once.

^{Reviewed by Cursor Bugbot for commit 8360b0f6ca4aac215cbc9e119bf1601999f75205. Configure here.}

Fixed in 1f8e906e7f. Two changes: /usr/bin/python3 is named absolutely first so launchd's bare PATH still finds it; and "held" is now only ever the script's own printed verdict. A probe that never ran — no interpreter on any candidate, or Apple's shim on a Mac without the developer tools (exits non-zero after an install prompt, never reaching the script) — 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. Tests cover a real fcntl holder, a missing interpreter, and a shim-like non-zero exit.

A stray second /** opener was introduced above this doc block while the registry was reworked, so the comment now starts twice. Consider dropping the extra line.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 3f1dbc880d — stray opener dropped.

🟠 High BrowserImport/FirefoxCookies.ts:55

Cookies with Firefox’s valid SAMESITE_UNSET value (0) are imported as sameSite: "no_restriction", changing ordinary cookies with no SameSite attribute to cross-site unrestricted cookies. Map SAMESITE_UNSET to Electron’s "unspecified" value instead, and update ImportedCookie to allow that value.

🟡 Medium BrowserImport/FirefoxCookies.ts:61

Pre-15 Firefox profiles import cookies with sameSite = 1 and rawSameSite = 0 as Electron lax, even though those rows had no SameSite attribute and must be imported as unspecified. sameSiteFromColumn ignores rawSameSite, so importing a schema 10–14 database before Firefox runs its schema-15 migration changes the cookies’ SameSite semantics. Read rawSameSite and apply the migration’s SAMESITE_UNSET rule before mapping the value.

Confirmed and fixed in 89623849ea. The reader now selects rawSameSite only when user_version is 10–14 (the column does not exist outside that range) and applies Firefox's own schema-15 migration rule: sameSite = LAX && rawSameSite = NONE → unspecified. Test covers defaulted-Lax, declared-Lax and explicit-None rows on a schema-14 fixture.

🟠 High BrowserImport/FirefoxCookies.ts:78

Reading a valid Firefox schema-9 database fails for the entire cookie set when any pre-existing cookie has sameSite = NULL, so no cookies are imported. The schema-9 migration adds sameSite without a default, and decodeCookieRows requires every value to be a number; allow NULL and normalize it to "unspecified" (for example, with COALESCE in the query or in the decoder).

HostProcessAddresses now holds an unmemoized Effect, so this yield* yield* re-runs the hostname resolution on every call — isSourceRunning invokes firefoxProfileIsHeld once per profile inside Effect.forEach, so a profile list of n costs n DNS lookups. It also runs before the win32 early return, where windowsLockIsHeld never uses the set.

Consider acquiring the addresses once in isSourceRunning and passing them into firefoxProfileIsHeld, the way firefoxSymlinkLockIsHeld already takes localAddresses as a parameter; that also removes the yield* yield* from the per-profile path.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in a0bec9dd1c: isSourceRunning resolves HostProcessAddresses once (and not at all on win32, where only parent.lock is consulted) and passes the set into firefoxProfileIsHeld, so the hostname lookup no longer runs per profile.

The default-container rationale now heads the hasRawSameSite computation, which it does not describe — the where originAttributes = '' predicate it explains moved down to the queries below. Consider keeping it next to that predicate.

^{Posted via Macroscope — Effect Service Conventions}

Moved back beside the where originAttributes = '' predicate in a66f319cbd.