feat(desktop): import browser cookies into a profile#7255

BrowserImport/ChromiumCookies.ts:58

This failure is translated straight into the BrowserImport service error channel, but it is a plain Error (the only one in apps/desktop/src) whose only data is a nested failure object, and readMacKeychainPassword throws it without retaining the keychain error as cause. Consider declaring it with Schema.TaggedErrorClass and flat structural attributes, e.g. reason: Schema.Literals([...]) plus cause: Schema.optional(Schema.Defect()), with message derived from reason, and pass the caught keychain error through as cause.

No longer relevant as of 58530950a4e4ec0a1743ac0ee2826ceba41af020

BrowserImport/BrowserImport.ts:131

The ChromiumCookieReadError (and any unexpected defect) is reduced to a reason string and the original error is dropped, so the stack and keychain details are unrecoverable. Suggest keeping it as cause alongside the structural fields, as BrowserSession does.

No longer relevant as of 58530950a4e4ec0a1743ac0ee2826ceba41af020

BrowserImport/BrowserImport.ts:140

This discards a structured domain error (BrowserSessionPartitionDerivationError / BrowserSessionCreationError) and relabels it as "readFailed", which reports a cookie-read problem for a partition/session failure. Suggest preserving the upstream error as cause and using a distinct reason.

No longer relevant as of 58530950a4e4ec0a1743ac0ee2826ceba41af020

BrowserImport/BrowserImport.ts:45

reason: Schema.String is an unstructured attribute, and the error carries no cause, so the real failure (keychain error, session creation error, Electron rejection) is lost. Consider typing reason as a literal union and adding an optional cause; the renderer currently recovers the reason by substring-matching this message (IntegrationsSettings.tsx runImport), which is exactly the fragility a typed discriminator avoids.

The "unknown source" construction below would become "unknownSource".

No longer relevant as of 58530950a4e4ec0a1743ac0ee2826ceba41af020

🟠 High BrowserImport/BrowserImport.ts:122

importCookies passes the IPC-controlled sourceProfileDirectory directly to cookieDatabasePath, so .. segments let a forged request escape the browser user-data directory and read/import cookies from another reachable Cookies database. Validate the directory against listSourceProfiles(definition) and enforce resolved-path containment before calling readChromiumCookies.

No longer relevant as of 58530950a4e4ec0a1743ac0ee2826ceba41af020

Host-only cookies widened on import

High Severity

Imported cookies always pass domain into session.cookies.set. Electron only creates a host-only cookie when domain is omitted; any provided domain is normalized with a leading dot and becomes valid for subdomains. Chromium host-only rows (no leading dot in host_key) therefore get a wider scope after import than they had in the source browser.

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

Snapshot races keychain consent wait

Medium Severity

browserRunning is checked once before the untimed Keychain modal, but the cookie DB snapshot runs only after that modal returns. If the source browser starts while the prompt is open, the import can copy a live WAL database anyway, which is the torn-read case the snapshot was meant to avoid.

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

🟡 Medium BrowserImport/ChromiumCookies.ts:162

importCookies can snapshot a database while Chromium is writing it, producing a torn snapshot that fails to open or silently omits recent cookies. The earlier running-browser check can become stale while readMacKeychainPassword waits for approval, and copying Cookies, Cookies-wal, and Cookies-shm separately does not form an atomic SQLite snapshot; recheck immediately before snapshotting and use SQLite's backup mechanism or otherwise prevent writes for the entire snapshot.

No longer relevant as of 3264ff7a4a32d791ea62c6b4e3338440b6e06a78

Import creates profile then no-ops

Medium Severity

importInto with target "new" always calls createProfile before runImport. runImport returns silently when environmentId or previewBridge is missing—no toast. The user gets an empty profile and no import feedback whenever the primary environment is not ready yet.

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

🟡 Medium

https://github.com/pingdotgg/t3code/blob/76fc9d21cb04161223f2cb6ce10ee2e146778199/apps/web/src/components/settings/IntegrationsSettings.tsx#L589

Removing a profile can leave its cookies or cache on disk while the profile entry is already gone, with no error or retry path. removeProfile closes the dialog and calls updateSettings without awaiting clearCookies/clearCache, and the per-call .catch(() => undefined) suppresses cleanup failures; await successful cleanup before updating settings, or retain the profile and expose a recoverable error when cleanup fails.

🟡 Medium settings/IntegrationsSettings.tsx:801

With no primary environmentId, “Clear cookies and cache” remains enabled but clearProfileData returns immediately, so the menu closes without deleting anything or showing a toast. Disable this action when clearing is unavailable.

✅ Resolved in d35f0a79a17ce3d07afd8e9b24ef0515f120a47b

Unsupported sources clutter import menu

Low Severity

unavailableReason returns unsupportedPlatform before install detection, and the UI only hides notInstalled. On Windows/Linux, mac-only Helium therefore always appears as a disabled “unsupported platform” row even though it can never be imported there—the same “nothing to act on” case the notInstalled filter was written to remove.

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

Stale running check after Keychain

Medium Severity

browserRunning is checked only before the Keychain read, and that read is deliberately untimed. The source browser can start while the modal is up, then snapshotCookieDatabase runs against a live WAL-backed DB—the case SingletonLock was meant to block—producing torn or incomplete cookie imports without a clear failure.

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

🟠 High BrowserImport/Sources.ts:98

When Local State is unreadable or malformed, listSourceProfiles returns only Default, so isSourceInstalled checks only Default/Cookies and reports an installation with cookies in Profile 1 as notInstalled. This hides an otherwise valid source; the fallback should discover available profile directories (or otherwise check profile databases) instead of restricting the check to Default.

✅ Resolved in 40385efaf3d51c5a7b12f40de484d364c39b63d0

🟠 High BrowserImport/ChromiumCookies.ts:35

Partitioned Chromium cookies are imported as ordinary unpartitioned cookies, so a CHIPS cookie becomes available outside its original top-level-site partition and may send a session identifier in unrelated browsing contexts. ChromiumCookie carries no partition-key metadata, and the import path therefore cannot pass it to Electron; preserve and write the partition key, or skip and count partitioned rows.

No longer relevant as of 05fe2c1c07af19afd480b84df6fc54f11a5ef45a

Stale Local State profiles listed

Medium Severity

When Local State is present, listSourceProfiles returns every declared profile without checking for a Cookies database. The filesystem scan fallback already requires a cookie DB. Profiles that remain in metadata after their directory was removed still appear in the import menu and then fail with a generic readFailed.

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

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

No longer relevant as of a7d72de122b9cf679eeed4ac8fada652fc3455fd

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.

^{Posted via Macroscope — UI Consistency}

Untracked imports after wizard close

High Severity

The prior busy lock on Add profile was removed, and dismissing the wizard during importing only clears importSource—it does not cancel or track the IPC work. Users can start another import (or hit the profile cap) while the first run is still finishing, so registrations race and target can stay new after canCreateProfile flips false.

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

Stale profiles wiped after import

High Severity

After importBrowserCookies returns, a new profile is registered by spreading a render-closed userProfiles into updateSettings, which replaces the whole browserProfiles list. The Keychain prompt and cookie write can outlive the wizard, so any profile created or removed in that window is overwritten when registration finally runs.

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

Done copy contradicts skips

Low Severity

When imported is 0 but cookies were skipped, DoneStep still says there were no cookies to bring over while also rendering the new Skipped hosts panel. That pairing is contradictory for all-decrypt or all-write failures.

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

🟡 Medium settings/BrowserImportWizard.tsx:356

When imported is 0 and skipped is positive, DoneStep renders “Nothing to import” and says there were no cookies, omitting the failed skipped count. The title and description should distinguish an all-skipped import from an empty cookie store.

Fixed in 37cdc249ab. An all-skipped result is distinguished from a source with no cookies; it reports failure to import and the skipped count/sites.

🟠 High BrowserImport/ChromiumCookies.ts:224

Cookies with an empty encrypted_value are imported with value: "" instead of their stored plaintext value. Chromium keeps plaintext cookies in the value column when encryption is unavailable, but this query neither selects nor retains that column; select value and use it when encrypted_value is empty.

🟡 Medium settings/BrowserImportWizard.tsx:41

A persisted profile whose id is "new" is displayed as an existing target but runImport treats the selection as kind: "new", so importing after selecting that profile updates a generated profile instead and can create one even at the profile cap. Use a sentinel outside the valid BrowserProfileId space or model the new/existing choice separately.

Fixed in 5483e8d898. New versus existing targets are tagged variants; a real profile whose id is new is no longer mistaken for the create-profile action. Regression coverage includes that id.

🟡 Medium BrowserImport/BrowserImport.ts:222

The import reports success before persistent cookies are flushed, so an import of fewer than 512 cookies can be lost on an app crash or forced termination despite cookies.set having succeeded. Call and await session.cookies.flushStore() before returning the result, and propagate a flush failure.

No longer relevant as of a7d72de122b9cf679eeed4ac8fada652fc3455fd

🟢 Low settings/BrowserImportWizard.tsx:356

The success title renders Imported 1 cookies when exactly one cookie is imported. Make the noun singular for imported === 1, consistent with cookieCountLabel.

🟡 Medium BrowserImport/Sources.ts:156

isSourceInstalled reports false and hides the source when Local State contains a stale entry such as Default while an actual Profile 1/Cookies database exists. Because line 156 skips the directory scan whenever declared.length > 0, the real profile is never discovered; scan and merge filesystem profiles even when the cache is non-empty.

No longer relevant as of a7d72de122b9cf679eeed4ac8fada652fc3455fd

When every cookie is skipped (imported === 0, skipped > 0 — e.g. an unusable key), this screen now contradicts itself: the header says "Nothing to import" / "There were no cookies to bring over", while the panel added just below lists the sites whose cookies were skipped, and the skipped count is never shown because it only appears on the imported > 0 branch. A user who picked "You — 5,065 cookies" on the configure step is told nothing was there.

Consider giving the all-skipped case its own copy so the header agrees with the panel.

^{Posted via Macroscope — UI Consistency}

Fixed in 37cdc249ab. All-skipped and genuinely empty results are separate cases, so zero imported does not claim the source had no cookies.

🟠 High BrowserImport/ChromiumCookies.ts:104

sameSiteFromColumn converts Chromium's stored UNSPECIFIED value (-1) to explicit `

✅ Resolved in 779b12083c33dab8537e94273cd2b679abc690d9

Expired cookies overwrite target sessions

Medium Severity

Already-expired source cookies are converted to a past expirationDate and written with cookies.set. Chromium treats that as a delete (expired-overwrite), so importing into an existing profile can remove matching live cookies. Those rows also increment imported even though they do not persist, which disagrees with BrowserImportResult treating expired cookies as skipped.

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

🟡 Medium BrowserImport/ChromiumCookies.ts:225

Legacy clear-text values in encrypted_value are returned as null, so readChromiumCookies counts those rows as undecryptable and drops otherwise valid cookies. Chromium treats values without the v10 prefix as legacy clear text; return buffer.toString("utf8") for that branch instead.

Fixed in 9bad21232a. Unversioned encrypted_value blobs use Chromium’s legacy plaintext behavior on macOS only. Linux unknown schemes remain unsupported. Fixtures cover both paths.

catch: () => undefined throws the Electron rejection away (no cause, no log), and Effect.catchCause then also converts defects and interruption into written = false, so an interrupted import silently keeps looping over the remaining cookies instead of stopping. Consider keeping the rejection as the typed error, logging it, and handling only the error channel with Effect.catch.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 461ee21f37. Only typed cookie-write rejections are counted as skipped; interruption and defects are not swallowed. The interruption test proves the write loop stops.

stat fails with a typed PlatformError, so catching the full cause here is wider than intended — it also turns a defect or an interrupt into a readLink attempt. Effect.catch handles the whole (statically known) error channel without touching defects or interruption.

^{Posted via Macroscope — Effect Service Conventions}

The new wording promises something the app doesn't do: a tab's profile is fixed at attach (HostedBrowserWebview documents this, and usePreviewWebviewConfig derives the partition from snapshot.profileId), so a tab already open in the removed profile keeps running in that partition — it doesn't move to the default. What the user sees instead is the profile badge in PreviewChromeRow disappearing (because activeProfile no longer resolves), which makes the tab look like it switched while its clear actions still target the removed profile's partition.

Consider describing what actually happens.

^{Posted via Macroscope — UI Consistency}

Fixed in 8560cddf38 and preserved in 7ee3c4f0c5. Removal copy no longer claims open tabs switch profiles. Tabs keep their original partition and show Removed profile when metadata is gone.

Dropping the browser-default-profile entry removes the only way to reach this setting from settings search, but the setting itself still exists — it moved into each profile row's Set as default. searchSettings substring-matches titles only, so "default browser profile" (and "default profile") now return nothing, while the three sibling defaults — viewport, zoom, appearance — still resolve.

Since targetId ?? id is what the jump scrolls to, an entry can point at the profiles row without owning an anchor of its own:

^{Posted via Macroscope — UI Consistency}

Fixed in 23950d7c31. The Default browser profile search entry targets the existing browser-profiles row, with search coverage.

Effect.catchTag isn't the convention here — statically known tagged failures should be recovered with Effect.catchTags({ ... }), including when only one tag is handled.

^{Posted via Macroscope — Effect Service Conventions}

🟠 High BrowserImport/Sources.ts:207

A stale SingletonLock symlink makes isSourceRunning return true, so after a crash or force-quit every import is rejected as browserRunning even though no browser is using the database. The lock target contains the host/PID but is never checked; validate that process is still alive (or remove stale locks) before reporting the source as running.

Fixed in a47eec8048 and 0524c56a20. Chromium host-PID locks are ignored only when a same-host PID is positively absent (ESRCH from signal 0). Live, denied, foreign-host, malformed, and unknown cases remain conservative. No lock is removed and no actual process signal is sent. Focused liveness/lock tests pass.

The row menu now hosts Set as default, which is a purely local client setting, but the trigger stays disabled until an environment catalog is ready. This PR also deletes BrowserDefaultProfileSetting, whose select was enabled whenever isElectron — so on desktop before a server connects there is no longer any way to change the default profile, and the dead icon button carries no explanation (the removal button it replaced had a Tooltip saying why).

The two environment-dependent items already gate themselves with disabled={!removalAvailable} (which is stricter than environmentsReady), so the trigger gate is redundant for them.

^{Posted via Macroscope — UI Consistency}

Fixed in 649be8a030. The profile menu no longer requires environment readiness, so Set as default remains available. Clear/remove retain their stricter cleanup-availability guards, and import/runtime pending restrictions remain.

The import targets whatever usePrimaryEnvironment() happens to be, but a browser profile is one Electron partition per environment (resolvePartitionScope(environmentId, profileId)), which is exactly why the two sibling actions in this component enumerate environments instead: clearProfileData and removeProfile call clearBrowserProfileData(..., environments.map(...)), with a test asserting it "clears every known environment". So with two environments connected, the cookies land in the primary one's partition only, while the wizard reports Imported N cookies — Added to <profile> with no mention of which environment; a preview tab opened under that profile in the other environment is still signed out, and the settings surface never names the environment it picked.

Consider either fanning the import out the way the clear path does (one importBrowserCookies per known environment id, reporting the aggregate once), or — if a single target is intentional — naming the environment in the configure and done copy so the result isn't presented as profile-wide.

No diff: the fix spans the IPC call site and the wizard's result copy.

^{Posted via Macroscope — UI Consistency}

Fixed in 6dd58889ef and 52c95d7d2f. Import intentionally targets one environment: the wizard captures its id and label when opened, uses that id throughout retries, and names the environment in configuration and results. Copy says for the environment because storage remains desktop-local; cookies are not fanned out to other environments.

DialogPopup renders its close button by default, but onOpenChange refuses to close while step.step === "importing" — so during the import the X is visible, focusable and enabled, and clicking it (or pressing Escape) silently does nothing. The repo's other non-dismissible-while-busy dialog ties the two together instead (RelayClientInstallDialog uses showCloseButton={isConfirming}, and SshPasswordPromptDialog/RenameEntryDialog pass false), so the affordance is only shown when it works.

^{Posted via Macroscope — UI Consistency}