feat(desktop): import browser cookies into a profile

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}

[juliusmarminge]

Stacked on #7272 (shared-sqlite-client).

Imports cookies from Helium on macOS into a T3 Code browser profile. Saved passwords and browsing history remain out of scope.

The app requests the browser key through the in-process Keychain API, so consent belongs to T3 Code. Denial stops the import; there is no permission bypass. Source databases are opened read-only and snapshotted consistently with SQLite before extraction.

The wizard chooses a source and destination, prevents profile edits during an import, and reports imported/skipped counts and affected sites. Plaintext and encrypted cookie records are handled separately; domain-bound records are validated. Partitioned cookies are skipped when their partition semantics cannot be preserved by Electron.

Validation includes synthetic decryption records, plaintext and legacy records, domain-binding failures, partitioned-cookie rejection, WAL snapshot consistency, interrupted writes, and wizard state transitions, plus scoped typechecks/lint. Earlier Helium imports were verified in the desktop app; this audit did not request another live Keychain read.

Original implementation: Claude Code. Review fixes: GPT-5.6 Sol agents, coordinated through Codex.

Note

Add BrowserImport service and wizard to import browser cookies

• Introduces BrowserImport service and IPC handlers to read, decrypt, and write Chromium cookies into a target profile partition
• Adds BrowserImportWizard UI to guide users through source and target selection, showing quit, blocked, and success screens
• Replaces inline client-settings persistence with a serialized queue so concurrent updates execute in order and publish only after durable writes succeed
• Adds @napi-rs/keyring dependency and build staging to package native keychain binaries for desktop artifacts
• Risk: persistClientSettingsUpdate now delays in-memory snapshot publication until persistence completes and rejects on failure; optimistic patches made during an awaited update are reapplied

^{Macroscope summarized d22663d.}

---

Note

High Risk
Reads third-party cookie databases and macOS Keychain secrets and writes session cookies into app partitions; correctness and hardening (path validation, partition alignment) directly affect auth/session security.

Overview
Adds browser cookie import from installed Chromium-family browsers (initially Helium on macOS) into T3 Code preview profiles. The desktop main process gains a BrowserImport service that lists sources, blocks import while the source browser is running, validates profile paths against traversal, reads cookies via a consistent SQLite snapshot and in-process Keychain access (@napi-rs/keyring), then writes into the same Electron partition the preview webview uses. New IPC/preload endpoints expose listBrowserImportSources and importBrowserCookies; contracts define sources, failure reasons, and results.

The Integrations browser profiles UI is reworked: Add profile opens a menu for a blank profile or Import from a detected browser, with a multi-step BrowserImportWizard (quit browser, pick source/target, progress, skipped domains). Default profile moves into per-profile row actions; the standalone default-profile setting row is removed. New profiles are persisted only after a successful import with cookies, using a new persistClientSettingsUpdate queue so registration does not race other settings writes.

Desktop release builds stage @napi-rs/keyring native binaries like existing passkey addons. Extensive unit tests cover decryption edge cases, lock detection, and wizard logic.

^{Reviewed by Cursor Bugbot for commit d22663d. 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: daf12449-bccc-4c49-a6df-572e284b0f18

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

[macroscopeapp]

Reviewed the new BrowserImport service, its Chromium cookie helper, and the IPC/layer wiring against the Effect service conventions.

Service shape, module layout (Context.Service tag + inline interface, make, layer), namespace imports, and layer composition in main.ts all look correct. The findings below are about the error model: the new failure type is unstructured (reason: Schema.String) and every construction discards the underlying cause, including one that erases a structured BrowserSession error.

^{Posted via Macroscope — Effect Service Conventions}

[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	—	13.3 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.1 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.3 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	55.5 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	8	—	21	✅

Baseline: unavailable · PR result: d22663d · 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: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

UI Consistency

One finding in the changed browser-profiles UI (apps/web/src/components/settings/IntegrationsSettings.tsx).

The menu/primitive usage itself looks consistent with the shared system: Menu/MenuPopup/MenuItem/MenuSub from components/ui/menu, MenuTrigger render={<Button …/>} matching the existing pattern in PreviewMoreMenu/ProjectScriptsControl, existing size="icon-sm" / variant="ghost-muted" Button variants, min-w-* on popups honouring MenuPopup's width-defaulting contract, and the bordered list container matching the convention already used in ConnectionsSettings. aria-labels are preserved on both the rename input and the new row trigger.

The issue is a state-display regression introduced by removing the default-profile Select while filtering Incognito out of the new list: a stored default of incognito (which the removed Select allowed a user to pick) now leaves the section with no "Default" badge on any row.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new desktop workflow that reads and decrypts browser authentication cookies through the OS keychain, then writes them into Electron profiles, along with native packaging and settings changes. The sensitive-data scope and unresolved runtime/UI risks warrant human review.

Not approved because:

• 3 blocking correctness issues found at or above your repo's Minimum Blocking Severity

No code changes detected at b4a5e28. Prior analysis still applies.

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

Reviewed the new BrowserImport service, its Sources/ChromiumCookies helpers, the IPC method, and the layer wiring against the Effect service conventions. The service module follows the canonical shape (errors → Context.Service with inline interface → make → layer), dependencies are acquired from the environment, and the failure translations now keep a real cause. One remaining gap on error context.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

UI Consistency — 1 finding

The two issues flagged on earlier commits are addressed: loadSources now clears sources before each refresh, and resolvedDefaultId resolves against the rendered rows.

One consistency gap remains: with BrowserDefaultProfileSetting removed and Incognito no longer rendered as a row, the section can badge Default on a profile that is not the effective default (see inline comment).

Minor (not blocking): lines 507–529 now carry three consecutive doc comments for a single component — the "Create, rename, and remove browser profiles" and "Per-profile cookie import" blocks are leftovers from the removed/renamed pieces and could be folded into one.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Two findings in the reworked browser-profiles section. Both are about the settings UI now disagreeing with the runtime behaviour it configures, rather than styling.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

The new cap guard on the Import button (target.kind === "new" && !canCreateProfile) has no matching feedback, so it lands the user in a dead end: once canCreateProfile flips false the New profile tile is unrendered (line 270), nothing in Into looks selected, and Import is disabled with nothing said. The structurally identical case one line up — an existing target that disappeared — already renders targetFeedback telling the user to choose again, so the two now behave differently for the same problem.

Consider routing the cap case through the same message slot (and reusing targetUncreatable in the disabled expression below, so the condition isn't stated twice).

Suggested change

	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: undefined);
	consttargetMissing=
	target.kind==="existing"&&
	!targetProfiles.some((profile)=>profile.id===target.profileId);
	// The "New profile" tile is unrendered once the cap is reached, so a target
	// chosen before that leaves nothing selected in "Into".
	consttargetUncreatable=target.kind==="new"&&!canCreateProfile;
	consttargetFeedback=
	targetError??
	(targetMissing
	? "That profile is no longer available. Choose where to import these cookies."
	: targetUncreatable
	? "You've reached the profile limit. Choose an existing profile to import into."
	: undefined);

^{Posted via Macroscope — UI Consistency}