feat(desktop): import cookies from Safari#7262

🟡 Medium BrowserImport/SafariCookies.ts:65

A truncated page is accepted as a successful import, so cookies after the truncated boundary are silently omitted. Buffer.subarray clamps pageStart + pageSize to the available buffer length; validate the declared page range and throw SafariCookieReadError("readFailed") before creating the page slice.

✅ Resolved in 3df1bbe3d13a59d55a7fd6213ee9d1e27e66bfbd

SameSite flags ignored

Medium Severity

Safari’s cookie flags field encodes SameSite in bits 3–5 (0x20 none, 0x28 lax, 0x38 strict), but every imported cookie is hard-coded to lax. Cross-site None sessions can fail after import, and Strict cookies are widened to lax.

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

Leaving lax. The reference descriptions of bits 3–5 disagree (creachadair's gist says 4/5/7 = None/Lax/Strict; interstateone/BinaryCookies calls them unknown), and the histogram of those bits on a real Safari 27 jar does not match either encoding cleanly. Guessing wrong toward none widens every cookie; lax is the browser default. Corrected the code comment in 9611ffbea so it no longer claims the format has no such field.

TCC denial misdetected

High Severity

needsFullDiskAccess is only returned when Effect reports PermissionDenied, which maps from EACCES. macOS TCC blocks on Cookies.binarycookies with EPERM, which Effect treats as Unknown, so real Full Disk Access denials surface as generic readFailed instead of the FDA remedy. The test covers chmod (EACCES), not TCC.

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

BrowserImport/SafariCookies.ts:47

SafariCookieReadError carries only reason and cause, so a TCC denial and a corrupt jar both log without naming the file that was read. The path is available at every construction site (readSafariCookies receives cookiePath, and parseBinaryCookies can take it as a parameter), and the sibling ChromiumCookieReadError already carries cookieDatabasePath for exactly this reason. Consider adding a cookiePath: Schema.String structural attribute and deriving the message from it, e.g. Could not read Safari cookies at ${this.cookiePath}: ${this.reason}.

No longer relevant as of a8129c16f241155f34b7753fffe6c2f2d989201c

BrowserImport/SafariCookies.ts:47

SafariCookieReadError carries only reason and cause, so a TCC denial and a corrupt jar both log without naming the file that was read. The path is available at every construction site (readSafariCookies receives cookiePath, and parseBinaryCookies can take it as a parameter), and the sibling ChromiumCookieReadError already carries cookieDatabasePath for exactly this reason. Consider adding a cookiePath: Schema.String structural attribute and deriving the message from it, e.g. Could not read Safari cookies at ${this.cookiePath}: ${this.reason}.

No longer relevant as of a8129c16f241155f34b7753fffe6c2f2d989201c

FDA denial reported as not installed

High Severity

Safari’s userDataDirectory is the TCC-gated Cookies folder. isSourceInstalled treats any probe failure—including PermissionDenied—as missing, so unavailableReason returns notInstalled and importCookies bails before readSafariCookies. Users without Full Disk Access never reach the needsFullDiskAccess path and see “Not installed” instead of the FDA remedy.

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

🟡 Medium BrowserImport/SafariCookies.ts:100

A page with an invalid header signature is accepted and its cookies are imported instead of failing with readFailed. parseBinaryCookies reads cookieCount without checking the required big-endian 0x00000100 signature; validate that field before parsing the page body.

No longer relevant as of 675447ae50083288dda5f455f8b164b3d6902a5a

🟡 Medium BrowserImport/SafariCookies.ts:65

A truncated record with no NUL terminator is accepted and imported, with the affected field containing all remaining record bytes instead of producing the promised readFailed error. readCString falls back to buffer.length when indexOf returns -1; throw SafariCookieReadError when no terminator is found within the record.

No longer relevant as of 675447ae50083288dda5f455f8b164b3d6902a5a

Wrong cookie record header size

Low Severity

COOKIE_RECORD_HEADER_SIZE is 48, but the fixed record layout runs through the creation f64 at bytes 48–55, so the header is 56 bytes. The comment and the test encoder both describe 56. The looser minimum lets truncated records past the malformation checks this parser otherwise enforces.

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

🟡 Medium BrowserImport/SafariCookies.ts:34

A truncated 48–55-byte record can pass validation and be returned as a fabricated cookie instead of producing readFailed. COOKIE_RECORD_HEADER_SIZE must be 56, and string offsets must also be rejected when they are below 56, because the f64 creation field occupies offsets 48–55.

Safari profiles cookies ignored

Medium Severity

Safari has been modeled as a single jar under Library/Cookies, with listSourceProfiles always returning one synthetic . profile. Since Safari 17, additional profiles keep cookies under Library/WebKit/WebsiteDataStore/<uuid>/Cookies/. Those jars are never listed or read, so imports miss that profile’s sessions, and a machine that only uses a named profile can look like Safari isn’t installed.

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

Intentional for v1: only the container jar is read. Documented in docs/user/browser-import.md (423564cbb) so users with Safari profiles know what to expect.

🟠 High BrowserImport/SafariCookies.ts:146

Host-only Safari cookies are imported with ImportedCookie.domain set to the bare host, so Electron treats them as domain cookies and widens them to subdomains (and rejects __Host- cookies). Set domain to undefined unless the source domain starts with ..

No longer relevant as of d7ea73ac1487159ef77bb8662246cf0700efdac3

Host-only cookies widened

High Severity

Safari always sets domain on imported cookies, including host-only ones (no leading dot). Chromium and Firefox go through cookieScope, which leaves domain undefined so Electron keeps them host-only. Passing domain makes Electron treat them as domain cookies (re-adding the dot), which widens scope to subdomains and causes __Host- cookies to fail at session.cookies.set.

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

The dialog's primary action can't open anything today: ElectronShell.parseSafeExternalUrl (apps/desktop/src/electron/ElectronShell.ts) only allows http:, https: and the editor remote schemes, so x-apple.systempreferences: is rejected, desktopBridge.openExternal resolves false, localApi.shell.openExternal throws "Unable to open link.", and .catch(() => undefined) swallows it. AlertDialogClose still dismisses the dialog, so the user is left with a button that closes the sheet and does nothing — the one recovery path this dialog exists to offer.

Smallest fix: add "x-apple.systempreferences:" to SAFE_EXTERNAL_PROTOCOLS (macOS-only is fine) and, so a future block isn't invisible, replace the bare .catch(() => undefined) with the existing failure toast telling the user to open System Settings → Privacy & Security → Full Disk Access manually.

^{Posted via Macroscope — UI Consistency}

FDA retry needs restart

Medium Severity

The Full Disk Access dialog keeps the failed import and offers “I've turned it on” to retry immediately. macOS Full Disk Access only applies after the app quits and relaunches, which also clears this in-memory pending state. Immediate retries keep failing with needsFullDiskAccess, and a real relaunch drops the held import so the button cannot complete the flow.

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

This still can't open anything, and after the move into BrowserImportWizard the button is now a complete no-op (it no longer dismisses the dialog either). ElectronShell.parseSafeExternalUrl (apps/desktop/src/electron/ElectronShell.ts) allows only http:, https: and the remote editor schemes, so x-apple.systempreferences: is rejected, desktopBridge.openExternal resolves false, localApi.shell.openExternal throws "Unable to open link.", and .catch(() => undefined) discards it. The user clicks the step's action and nothing happens or is said.

Smallest fix: allow the x-apple.systempreferences: scheme in SAFE_EXTERNAL_PROTOCOLS (darwin only), and surface a failure here instead of swallowing it — e.g. a toast in the catch, as ThreadTerminalDrawer does — so the step degrades to readable instructions rather than a dead control.

^{Posted via Macroscope — UI Consistency}

Wrong Full Disk Access URL

Medium Severity

FULL_DISK_ACCESS_SETTINGS_URL uses the query fragment Privacy_AllFilesAccess. Documented macOS deep links for Full Disk Access use Privacy_AllFiles. Even after the scheme is allowlisted, this URL may open the wrong pane or fail to land on Full Disk Access.

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

Settings deep link blocked silently

High Severity

Open System Settings calls shell.openExternal with an x-apple.systempreferences: URL. Desktop openExternal only allows http/https and editor schemes, so the call returns false, readLocalApi throws, and the handler’s .catch swallows it — the button does nothing.

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

BrowserImport/SafariCookies.ts:206

Parse failures still lose the path they occurred on: parseBinaryCookies throws without cookieDatabasePath, and the pass-through branch returns that error unchanged even though cookiePath is in hand here, so a corrupt jar logs Could not read Safari cookies: readFailed. with no file named. Consider threading the path into the parser (e.g. parseBinaryCookies(buffer, cookiePath) used at each throw new SafariCookieReadError({ reason: "readFailed", cookieDatabasePath })), which also lets cookieDatabasePath become required like ChromiumCookieReadError's.

No longer relevant as of 46430d0e1804d8d4350ba986269dbe277cb17691

🟠 High BrowserImport/Sources.ts:79

Chromium sources are now reported as unsupported on Windows, so BrowserImport rejects them before the reader can import still-readable DPAPI v10 cookies from databases that also contain unreadable App-Bound v20 records. Restore Windows platform/path definitions for Chromium sources so the supported partial-import path remains reachable.

Reviewed against the current scope and the Windows-tested contribution #7323. Windows Chromium import was deliberately removed at the maintainer’s request; restoring the retired DPAPI path is not a correction for this stack. Firefox remains supported on Windows. Resolving this as an intentional unsupported capability, not an outstanding regression.

Windows lock test never runs

Medium Severity

The new Windows parent.lock test only supplies HOME, but Firefox on win32 resolves its user-data directory from APPDATA. With that missing, userDataDirectory is undefined and isSourceRunning returns false before isLockHeld runs, so the assertion passes without covering the stale-lock regression it describes.

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

🟠 High BrowserImport/Sources.ts:312

isLockHeld reports Firefox as running for a stale read-only parent.lock or a profile directory without write access, even when no Firefox process holds the lock. The r+ probe maps those EACCES cases to PermissionDenied, and treating that error like Busy makes isSourceRunning return true and blocks cookie imports; only an actual sharing conflict should indicate an active lock.

FDA deep link uses wrong anchor

Medium Severity

The Full Disk Access deep link pairs the Ventura PrivacySecurity.extension pane with query Privacy_AllFilesAccess, carried over from the legacy preference.security URL. The documented anchor for this pane is Privacy_AllFiles. An unrecognized anchor typically opens Privacy & Security without jumping to Full Disk Access, so Open System Settings can land users on the wrong screen.

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

needsFullDiskAccess is now also a BrowserImportUnavailableReason, but only outcomeToStep routes it to the new screen. initialWizardStep still falls through to { step: "blocked", reason: source.unavailable }, and isRetryableReason returns false for it — so a source listed as unavailable for this reason opens on a dead-end screen whose copy says "…then retry" with no retry and no "Open System Settings" button, while the identical condition discovered at import time gets the recoverable step. It's latent today (the desktop only reports unsupportedPlatform/notInstalled/browserRunning pre-flight), but the two entry points should agree, the same way browserRunning maps to quit in both.

^{Posted via Macroscope — UI Consistency}

Fixed in the updated #7262. Initial Full Disk Access requirements route into the permission step and return to configuration after refresh; permission failure during a selected import preserves its retry path. Opening settings failures show actionable feedback rather than disappearing. Focused state-transition tests pass.

Resolving instead of throwing here makes the "Open System Settings" button a silent no-op on any shell whose preload predates openSystemSettings: the promise fulfils, so the .catch in IntegrationsSettings.tsx never fires and the "Could not open System Settings" toast never shows. The other guard there doesn't cover it either — readLocalApi() only returns undefined when window is undefined, so the !localApi branch is unreachable in the renderer.

Throwing keeps a single feedback path (the caller's toast telling the user where to click), matching openExternal above.

^{Posted via Macroscope — UI Consistency}

Fixed in 0369f309c0 on #7262. An unavailable System Settings bridge rejects with the established error, reaching the caller toast. A focused missing-bridge test covers this path.

recheckFullDiskAccess runs an async round-trip with no step change, unlike its sibling recheckAfterQuit which sets { step: "checking" } first. Pressing "I've turned it on" leaves the same screen mounted with no in-flight state, and when access is still denied refreshedSourceStep returns fullDiskAccess again — so the button looks dead in exactly the case the user is most likely to hit (toggling the checkbox requires relaunching the app on macOS).

Smallest fix: set an in-flight step before awaiting, as the quit path does, and give CheckingStep neutral copy (or a description prop) since "Checking whether the browser has closed." is wrong for this screen; a distinct message when the refresh still reports needsFullDiskAccess would also make the outcome visible.

Also, this path resets the source profile to refreshed.profiles[0] rather than going through refreshedSourceProfileDirectory, which the quit path uses to preserve the user's selection when the refreshed source still lists it.

^{Posted via Macroscope — UI Consistency}

Fixed in cfad01d520 on #7262. Full Disk Access refresh enters an explicit checking state with accurate copy, preserves the selected source profile through the shared helper, and shows a still-required message after denial. Initial permission and retry-import paths remain intact.

🟡 Medium

https://github.com/pingdotgg/t3code/blob/b99d5dd2476b927e86a541e0bd6e17f712486780/apps/desktop/src/preview/BrowserImport/BrowserImport.ts#L193-L199

Safari imports emit Reading browser cookie key from the keychain even though Safari never obtains a key, misleading logs and keychain-prompt diagnostics on every Safari import. Emit this log only for Chromium imports.

Fixed in b056322b87 on #7262. Keychain-read diagnostics now run only for macOS Chromium imports; Safari, Firefox, and Linux no longer emit the misleading message.

The two onGranted branches give different feedback for the same user action. recheckFullDiskAccess routes through fullDiskAccessRecheckStep, which sets checked: true and renders the "Full Disk Access is still required" panel; the resume === "import" branch calls runImport, whose failure goes through outcomeToStep and returns { step: "fullDiskAccess", resume: "import" } with no checked. So on the import-retry path the user presses "I've turned it on", sees a brief spinner, and lands back on an unchanged screen with nothing saying access is still denied — which is the common case, since granting Full Disk Access on macOS only takes effect after the app relaunches.

Smallest fix: mark the returned step as checked when the retry came from this screen, e.g. give runImport an afterAccessGrant flag that maps a fullDiskAccess outcome to { ...next, checked: true }, and call () => runImport(true) here. (Alternatively, add checked: true to the needsFullDiskAccess branch of outcomeToStep, which also shows the panel on first arrival.)

^{Posted via Macroscope — UI Consistency}

Fixed in 4799270451 on #7262. An import attempt denied Full Disk Access now returns checked:true, showing the same still-required feedback as a permission refresh. The state-transition test covers it.

🟠 High BrowserImport/Sources.ts:413

When Network/Cookies is a directory and the valid legacy Cookies database exists, countProfileCookies selects the directory first, the SQLite query fails, and the legacy candidate is never tried. The importer uses the same candidate selection and therefore also fails instead of importing the profile; filter candidates to regular files in both paths.

🟠 High BrowserImport/Sources.ts:447

When profiles.ini lists only profiles without cookies.sqlite, listSourceProfiles returns an empty list without scanning for other profiles, so isSourceInstalled returns false and hides cookies in an unlisted profile. Continue to the fallback directory scan when found is empty, rather than returning whenever declared is non-empty.

Fixed in 78c57bad1d. When none of the declared profiles has a cookie database, listing now falls through to the Profiles directory scan instead of returning empty, so cookies in an undeclared profile are found and isSourceInstalled stays true. Regression test covers a profiles.ini that names only a never-launched profile.

🟠 High BrowserImport/SafariCookies.ts:202

readSafariCookies successfully imports a truncated/partial jar while silently omitting cookies from complete pages left as trailing bytes. parseBinaryCookies validates each declared page but never checks that the final pageStart equals buffer.length; add that validation so trailing data causes readFailed instead of a partial import.

Fixed in 453644b15e. The parser now requires the bytes after the declared pages to be exactly what Safari writes — nothing, the 8-byte checksum, or checksum + u32 length + that many property-list bytes — and refuses anything else, so a jar with undeclared trailing pages is readFailed rather than a partial import. Tests cover the valid trailers and both the extra-page and bad-length cases.

🟠 High BrowserImport/SafariCookies.ts:176

isPermissionDenied reports ordinary EACCES failures as needsFullDiskAccess, so jars blocked by POSIX permissions or ACLs send users to a grant that cannot fix the failure. Since the Safari TCC path is identified by EPERM, only classify that errno as needsFullDiskAccess and let other permission errors remain readFailed.

🟡 Medium BrowserImport/SafariCookies.ts:105

Malformed pages can place cookieStart inside the page header/offset table or overlap a previously parsed record, allowing those bytes to be interpreted as a fabricated cookie. The check at line 107 only verifies page bounds; require cookieStart to start after the complete offset table and reject overlapping record ranges before parsing the record.

🟠 High BrowserImport/SafariCookies.ts:102

parseBinaryCookies rejects valid Safari pages, so ordinary one-cookie jars fail to import. offsetTableEnd should start at byte 8, but the current 12 + cookieCount * 4 makes a record offset of 12 fail the cookieStart < offsetTableEnd check; use 8 + cookieCount * 4 instead.

FDA check skips named Safari jars

Medium Severity

listSafariProfiles can mark Safari installed from a named-profile jar, but the listing-time Full Disk Access probe still only opens the default "." jar. If that default jar is missing, TCC denial is not reported up front, so Safari looks ready or notInstalled instead of opening the permission step.

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