feat(desktop): resolve Chromium cookie keys on Linux

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[juliusmarminge]

Stacked on #7260 (browser-import-more-sources). Despite the retained branch name, this PR adds Linux support only; Windows Chromium is intentionally unsupported.

Chromium cookie key handling moves into a platform-specific module:

Platform	Scheme	Key source
macOS	v10 AES-128-CBC	Login Keychain, with consent
Linux	v10 AES-128-CBC	Chromium’s basic-storage peanuts passphrase
Linux	v11 AES-128-CBC	Secret Service via secret-tool, using the browser’s application attribute

Linux requires secret-tool and a compatible Secret Service backend to import v11 records. Missing keys/tools/backend can yield a partial v10 import; skipped records are reported. Explicit permission denial or cancellation stops the import. Secret bytes are preserved apart from the tool’s output line ending.

There is no DPAPI, PowerShell, App-Bound Encryption bypass, or direct KWallet implementation. macOS keeps the existing in-process consent path.

Validation: synthetic v10/v11 decryption fixtures, mocked Secret Service subprocess results, denied/missing backend behavior, and trailing-whitespace preservation. No live Linux keyring lookup was performed during this audit.

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

Note

Add Linux support for resolving Chromium cookie keys

• Enables Chromium browser cookie imports on Linux by resolving v10/v11 keys via the Secret Service (secret-tool) and macOS keychain.
• Introduces ChromiumKeys.ts to handle platform-specific key resolution, including Linux empty-passphrase fallbacks and optional v11 keys.
• Updates ChromiumCookies.ts to decrypt v10/v11 records with structured key material and strip SHA-256 domain bindings from schema 24+ cookies.
• Risk: readChromiumCookies now accepts ChromiumKeyMaterial instead of a single Buffer, and decryptChromiumValue treats unrecognized prefixes as cleartext on macOS and Linux.

^{Macroscope summarized 85465f1.}

---

Note

Medium Risk
Reads OS credential stores and spawns secret-tool to derive cookie decryption keys; behavior changes which Linux Chromium sources appear importable and may partially import when v11 keys are missing.

Overview
Enables Chromium cookie import on Linux by moving OSCrypt key resolution into ChromiumKeys and wiring each browser source with a linuxSecretApplication for libsecret lookup via secret-tool.

On Linux the importer always derives the v10peanuts key and an empty-passphrase retry key; it optionally loads v11 from Secret Service (chrome_libsecret_os_crypt_password_v2). Missing backend or secret yields a partial import (skipped cookies reported) while explicit unlock denial still fails the flow. macOS keeps in-process Keychain consent; Windows stays unsupported.

Decryption now takes a ChromiumKeyMaterial map: decryptChromiumValue handles v10/v11 prefixes, empty-key retry (crbug 1195256), schema-24 domain binding, and treats unprefixed blobs as legacy cleartext on macOS and Linux (aligned with Chromium).

Availability no longer blocks all non-macOS Chromium sources up front—unavailableReason only checks declared platforms, install, and running state; key errors surface during read. BrowserImport passes linuxSecretApplication and requires ChildProcessSpawner for the cookie read path.

^{Reviewed by Cursor Bugbot for commit 3c1d584. 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: 2a0d1595-8e5e-4594-b3da-057657d6ef1a

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

[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.4 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.6 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	10	—	21	✅
Claude	Total thread wire	—	13.3 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	6.9 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	56.4 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	10	—	21	✅

Baseline: unavailable · PR result: 85465f1 · 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]

Reviewed the new ChromiumKeys module and its call sites against the Effect service conventions. Imports, Effect.fn.Return requirement typing, and dependency acquisition (yield* FileSystem.FileSystem, ChildProcessSpawner surfaced in the requirement channel and threaded through BrowserImport's captured context) all look right. Two error-modelling issues in ChromiumKeys.ts: an underlying failure is discarded instead of being preserved as cause, and the Windows DPAPI path can turn a real failure into a silently empty key reported under a misleading reason.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds Linux Chromium cookie importing with Secret Service access, external process execution, key derivation, and decrypted session-cookie handling, creating substantial runtime and sensitive-data impact. It also adds a static-analysis diagnostic suppression, so the changes require human review.

No code changes detected at 85465f1. Prior analysis still applies.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding: a typed ChromiumKeyError is re-wrapped at a translation boundary in ChromiumKeys.ts, losing its reason and nesting the error inside itself.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Reviewed the new ChromiumKeys module and its call sites in ChromiumCookies/BrowserImport against the Effect service conventions. Two findings on error modelling in ChromiumKeys.ts; the layer/import/dependency-acquisition side looks fine (resolveChromiumKeys takes FileSystem/ChildProcessSpawner from the environment and scopes the child process locally).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding on the new key-material plumbing in ChromiumCookies.ts.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding: the new per-prefix key selection in ChromiumCookies.ts (the central behavior change of this PR) has no focused test. Everything else — the ChromiumKeys module layout, ChromiumKeyError structure, ChildProcessSpawner acquisition from the environment, and the test-only Layer.succeed spawner seam — follows the Effect service conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One finding, on the new test file's diagnostic suppression. The rest of the change — the ChromiumKeys module layout, ChromiumKeyError structure with preserved cause, ChildProcessSpawner/HostProcessEnvironment acquired from the environment, requirements surfaced through Effect.fn.Return, and the now-uniform ChromiumKeyMaterial key shape with focused mixed v10/v11 coverage — matches the conventions.

^{Posted via Macroscope — Effect Service Conventions}