Overview
Browsernode supports a wide variety of ways to launch or connect to a browser:- Launch a new local browser using playwright/patchright chromium (the default)
- Connect to a remote browser using CDP or WSS
- Use an existing playwright
Page,Browser, orBrowserContextobject - Connect to a local browser already running using
browserPid
Connection Methods
Method A: Launch a New Local Browser (Default)
Launch a local browser using built-in default (playwrightchromium) or a provided executablePath:
chromium-based browsers in executablePath, including Brave, patchright chromium, rebrowser, Edge, and more. See examples/browser/stealth.ts for more. We do not support Firefox or Safari at the moment.
Method B: Connect Using Existing Playwright Objects
Pass existing PlaywrightPage, BrowserContext, Browser, and/or playwright API object to BrowserSession(...):
page directly to Agent(...) as a shortcut.
Method C: Connect to Local Browser Using Browser PID
Connect to a browser with open--remote-debugging-port:
Method D: Connect to remote Playwright Node.js Browser Server via WSS URL
Connect to Playwright Node.js server providers:Method E: Connect to Remote Browser via CDP URL
Connect to any remote Chromium-based browser:Security Considerations
Best Practices
-
Use isolated profiles: Create separate Chrome profiles for different agents to limit scope of risk:
-
Limit domain access: Restrict which sites the agent can visit:
-
Enable
keepAlive=trueIf you want to use a singleBrowserSessionwith more than one agent:
Re-Using a Browser
ABrowserSession starts when the browser is launched/connected, and ends when the browser process exits/disconnects. A session internally manages a single live playwright browser context, and is normally auto-closed by the agent when its task is complete (if the agent started the session itself). If you pass an existing BrowserSession into an Agent, or if you set BrowserSession(keepAlive=True), the session will not be closed and can be re-used between agents.
Browsernode provides a number of ways to re-use profiles, sessions, and other configuration across multiple agents.
- ✅ sequential agents can re-use a single
userDataDirin newBrowserSessions - ✅ sequential agents can re-use a single
BrowserSessionwithout closing it - ❌ parallel agents cannot run separate
BrowserSessions using the sameuserDataDir - ✅ parallel agents can run separate
BrowserSessions using the samestorageState - ✅ parallel agents can share a single
BrowserSession, working in different tabs - ⚠️ parallel agents can share a single
BrowserSession, working in the same tab
Sequential Agents, Same Profile, Different Browser
If you are only running one agent & browser at a time, they can re-use the sameuserDataDir sequentially.
Make sure to never mix different browser versions orexecutablePaths with the sameuserDataDir. Once run with a newer browser version, some migrations are applied to the dir and older browsers wont be able to read it.
Sequential Agents, Same Profile, Same Browser
If you are only running one agent at a time, they can re-use the same activeBrowserSession and avoid having to relaunch chrome.
Each agent will start off looking at the same tab the last agent ended off on.
Parallel Agents, Same Browser, Multiple Tabs
Parallel Agents, Same Browser, Same Tab
Parallel Agents, Same Profile, Different Browsers
To share a single set of configuration or cookies, but still have agents working in their own browser sessions (potentially in parallel), use our providedBrowserProfile object.
The recommended way to re-use cookies and localStorage state between separate parallel sessions is to use the storageState option.
Troubleshooting
Chrome Won’t Connect
If you’re having trouble connecting:- Close all Chrome instances before trying to launch with a custom profile
- Check if Chrome is running with debugging port:
- Verify the executable path is correct for your system
- Check profile permissions - ensure your user has read/write access
Profile Lock Issues
If you get a “profile is already in use” error:- Close all Chrome instances
- The profile will automatically be unlocked when BrowserSession starts
- Alternatively, manually delete the
SingletonLockfile in the profile directory
For more configuration options, see the Browser
Settings documentation.
Profile Version Issues
The browser version you run must always be equal to or greater than the version used to create theuserDataDir.
If you see errors like Failed to parse Extensions when launching, you’re likely attempting to run an older browser with an incompatible userDataDir that’s already been migrated to a newer Chrome version.
Playwright ships a version of chromium that’s newer than the default stable Google Chrome release channel, so this can happen if you try to use
a profile created by the default playwright chromium (e.g. userDataDir='~/.config/browsernode/profiles/default') with an older
local browser like executablePath='/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'.