Subchapter 9.6
REFERENCE.mdMarkdown5 KBView on GitHub
Cookie sync is a Node.js script that uses:
@browserbasehq/stagehand) for CDP connections to both local Chrome and the cloud browser, including cookie get/set operations@browserbasehq/sdk) for API calls (context creation)Local Chrome (Stagehand) → cookie-sync.mjs → Stagehand (Browserbase) → Cloud Browser
↓ ↓ ↓
context.cookies() init() creates session context.addCookies()| Variable | Required | Description |
|---|---|---|
BROWSERBASE_API_KEY | Yes | API key from https://browserbase.com/settings (opens in a new tab) |
BROWSERBASE_CONTEXT_ID | No | Reuse an existing context instead of creating a new one |
CDP_URL | No | Direct WebSocket URL to Chrome (e.g. ws://127.0.0.1:9222). Use when Chrome is launched with --remote-debugging-port and no DevToolsActivePort file exists |
CDP_PORT_FILE | No | Custom path to DevToolsActivePort file |
CDP_HOST | No | Custom host for local Chrome connection (default: 127.0.0.1) |
The script finds Chrome’s DevTools WebSocket URL in one of two ways:
CDP_URL is set, it resolves the browser WebSocket endpoint from that debugging endpoint (or uses the full browser WebSocket URL directly)DevToolsActivePort file created by browsers that expose remote debugging through their normal profileCalls context.cookies() via Stagehand’s Understudy layer (which uses Storage.getCookies over CDP). This returns all cookies from all domains stored in the browser — not just the active tab.
Creates a Browserbase Context via the SDK (persistent state container) and a Stagehand session attached to that context with persist: true. This means:
keepAlive: true so it stays open until explicitly closedCalls context.addCookies() via Stagehand’s Understudy layer (which uses Storage.setCookies over CDP) to inject all exported cookies into the cloud browser.
Contexts persist browser state (cookies, localStorage, IndexedDB) across sessions.
node cookie-sync.mjs
# Output includes: Context ID: ctx_abc123BROWSERBASE_CONTEXT_ID=ctx_abc123 node cookie-sync.mjs| Browser | macOS | Linux | Windows |
|---|---|---|---|
| Google Chrome | Yes | Yes | Yes |
| Chrome Beta | Yes | Yes | — |
| Chrome for Testing | Yes | — | — |
| Chromium | Yes | Yes | — |
| Brave | Yes | Yes | Yes |
| Microsoft Edge | Yes | Yes | Yes |
| Vivaldi | — | Yes | — |
Chrome 146+ (recommended):
chrome://flags/#allow-remote-debuggingAny Chrome version (requires --user-data-dir and CDP_URL):
# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug
export CDP_URL=ws://127.0.0.1:9222
# Linux
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug
export CDP_URL=ws://127.0.0.1:9222
# Windows
chrome.exe --remote-debugging-port=9222 --user-data-dir=%TEMP%\chrome-debug
set CDP_URL=ws://127.0.0.1:9222Note: --user-data-dir is required because Chrome won’t open the debugging port with an existing profile. This means the debug instance starts with a fresh profile — your real cookies are not available. The chrome://flags method (Chrome 146+) does not have this limitation.
wss://) to Browserbase.keepAlive: true persist until explicitly closed — remember to close sessions when done.