Add Browserbase context to local Chrome skill

[YousefKhalil99]

Summary

Add a reverse companion to cookie-sync: copy cookies, localStorage, and IndexedDB from a Browserbase persistent context into a dedicated local Chrome profile for human use.

The skill supports domain filtering, keeps storage state in memory, and refuses to overwrite an existing unmanaged Chrome profile. It documents the limits of transferring browser state and links back from cookie-sync.

Validation

• node scripts/validate-skills.mjs — 19 passed, 0 failed; one pre-existing compatibility warning in optimize-agent-prompt.
• node skills/browserbase-context-to-chrome/scripts/test-e2e.mjs — passed using a disposable Browserbase context. A synthetic cookie and localStorage value survived the transfer, and a cookie for an unrelated domain was excluded.
• A headed Chrome run completed with a disposable context on httpbin.org. After the Chrome window closed, reopening its dedicated profile retained the synthetic cookie and localStorage value.
• npm ci passed with a fresh cache using the public registry.npmjs.org URLs in the lockfile.
• node --check passed for both scripts.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​playwright@​1.63.0
	npm/​@​browserbasehq/​sdk@​2.20.0

View full report

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

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

[shrey150]

maybe local-cookie-sync could be a better name?

[shrey150]

Tested 966e420 with real Browserbase sessions and local Google Chrome. The bundled E2E test passes, and fresh-profile headless transfers preserve cookies, localStorage, and IndexedDB across a Chrome restart. I reproduced three issues in the unmodified CLI:

1. Ctrl-C can lose imported persistent cookies (launch/shutdown code). Run headed with --all, wait for “Chrome is ready for use,” then send SIGINT. In the test, SIGINT was sent 1.5 seconds after that message; the process exited 130, and both imported cookies were absent after reopening the profile. localStorage and IndexedDB survived. These cookies had future expiration times, so this is separate from the documented session-cookie limitation. An isolated real-Chrome reproduction lost the cookie in 2/2 runs with the default SIGINT handling; adding handleSIGINT: false to launchPersistentContext let the script finish local.close() and preserved it in 2/2 runs. That fix candidate was tested locally, not applied to the PR.

2. Reusing a managed profile preserves unrelated old site storage (setStorageState). After a successful import, seed localStorage, IndexedDB, and a cookie for example.org in the managed profile; close Chrome; rerun the CLI into that profile with --domains example.com. The old cookie is cleared, but the unrelated origin’s localStorage and IndexedDB remain:

   {"localStorageRetained":true,"indexedDBRetained":true,"cookieRetained":false}
   

   This contradicts the documented replacement behavior and can retain authentication state from a previous transfer. Profile reuse needs to clear persisted origins beyond those in the incoming state.

3. Subdomain filtering exports parent host-only cookies (filter). Seed a host-only cookie on example.com and a domain cookie on .example.com, then run with --url https://www.example.com/ --domains www.example.com --headless. The CLI reports Transferred 2 cookies and 0 origins, and both cookies exist in the destination profile after restart, even though JavaScript at www.example.com sees only the domain cookie. Keep the host-only/domain distinction: parent cookies should match a selected subdomain only when they are domain cookies.

Other passing checks: npm ci, syntax checks for both scripts, all 19 skill validations (one pre-existing compatibility warning), 17 CLI validation/profile-safeguard checks, and headless --all persistence.

Environment: Linux, Node 24.15.0, Chrome 154.0.8037.92, Playwright 1.63.0, Browserbase SDK 2.20.0; headed Chrome ran under Xvfb. Tests used synthetic state on public example domains and disposable contexts/profiles, which were cleaned up. No PR source changes were made.

[shrey150]

pre-approving