Why does OpenClaw open a separate browser?
OpenClaw's managed openclaw profile has its own browser data directory. It can read and interact with pages, but it starts outside the browser profile you use every day. If it opens a site where your personal browser is already signed in, a sign-in screen can be the expected result. Select a named connection deliberately when the task depends on an existing session.
Start with a managed profile for a public page or a dedicated work account. Reach for an existing-session connection when the task belongs in an already authorized browser session. Before the first action, check the profile name, the target tab and an account or workspace marker. The same URL can show two different accounts in two browser profiles. OpenClaw Browser overview How to connect to an existing browser
Compare the browser routes
| OpenClaw profile | Browser it targets | Check first |
|---|---|---|
openclaw | Dedicated, OpenClaw-managed browser with its own data directory | Expected managed profile, reachable URL and whether this is a test account |
user | Existing Chromium-family browser through Chrome DevTools MCP | Exact browser profile, open tab and first-time debugging approval |
chrome | Tabs available through the OpenClaw browser extension | Extension connection, approved tab and visible workspace |
| Named remote profile | Browser reachable through an explicit CDP endpoint | Endpoint ownership, remote host, credentials and intended profile |
OpenClaw's documentation distinguishes the user and chrome profiles. The first uses an existing-session MCP attachment and Chrome may ask to approve remote debugging. The second uses an extension connection for supported tabs. A tutorial written for an earlier relay implementation may use the same name with different setup steps. Check the installed version and current docs before changing a driver. OpenClaw profiles Existing-session configuration
One user reported choosing user for an existing login but still seeing commands stall. An earlier extension user reported that the agent chose the managed openclaw profile instead of the expected relay. These are individual observations from different releases. They make the chosen profile and the actual tool response useful fields in a task receipt. Existing-session discussion Earlier extension discussion
Check the route before touching a page
In your authorized test setup, list the profiles and name the intended one on each command. The following commands come from the official setup and CLI references. A browser action in the wrong profile can land on a valid-looking page with the wrong account. These commands are examples, and the first run should be read-only.
openclaw browser profiles
openclaw browser --browser-profile openclaw status
openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw open https://example.com
openclaw browser --browser-profile openclaw snapshotUse a fixture you control for repeat tests. In the managed browser, verify the heading and final URL. For an existing-session test, open a harmless page in the intended test profile, approve the requested attachment and check the tab list before taking the snapshot.
openclaw browser --browser-profile user status
openclaw browser --browser-profile user tabs
openclaw browser --browser-profile user snapshotIf the existing-session profile has more than one tab, use the current CLI's tab selection options and verify the selected tab before proceeding. Pause when approval is unavailable, the tab list is empty or the workspace label is wrong. Browser setup CLI browser commands
Keep work accounts and profiles separate
An OpenClaw profile name identifies a route. A browser profile identifies stored browser data. If two named routes use the same existing user-data directory, they can point at the same account. To separate teams or environments, give each managed profile its own storage, then manually sign in to the intended test account where needed. For an attached profile, choose the exact approved browser profile and verify its visible workspace label. Browser configuration Manual browser login
Say you have a training workspace and a production workspace at the same URL. The acceptance check is a training workspace label and a known dummy record ID. Put both in the task prompt. If the label says production, stop before reading a record or filling a form. You can check the target without asking for the user's username or password. See browser profiles, workspaces and tab groups for the difference between storage and organization.
| Before the action | Keep in the receipt | If it differs |
|---|---|---|
| Route and account | Profile name, connection type and non-sensitive workspace label | Stop and switch to the approved profile |
| Target tab | Tab ID and final URL | Re-select the test tab |
| Expected page state | Visible heading or fixture ID | Re-read the page and report the mismatch |
| Task exit | Which tab was closed, and whether an attachment was released | Leave pre-existing user tabs open |
Verify the result and end the task
For a first run, ask for one known value from a test page. Add a click only after verifying the account and tab. If the action changes something, read back the updated value from the same record. A successful tool call can still leave the intended result unverified.
Use the named test profile and one approved test page. Return the profile, final URL, visible workspace label and the fixture ID. Stop if a login prompt, permission request or different workspace appears. Keep the task read-only and close only the tab you created.
When finished, close the test tab and leave any pre-existing user tabs alone. For your own isolated managed browser, stop that instance if no other task is using it. With an existing-session connection, release the connection and follow the product's controls if you need to revoke the permission. A timeout is a reason to check state before retrying, especially after a write. For a remote route, also confirm where localhost resolves. Cloud-agent localhost example First browser-agent task Checking a signed-in browser
What the two test routes returned
OpenClaw 2026.11.1 ran both routes on Node.js 24.16.0 against the same local test URL and record E08-FIXTURE. We used Tabbit Browser Dev in both cases, with two temporary data directories. The managed route launched its own test browser and read No signed-in workspace. For the second route, we first opened the fixture in a separate test browser and seeded a synthetic session cookie. OpenClaw attached to that existing browser with a named existing-session profile and explicit test userDataDir. Its status reported transport: chrome-mcp and its snapshot read Training workspace on the same record.
Stopping the attachment left the existing browser running. We shut down both test browser processes and the gateway after the check. The test verified a managed launch and a named existing-session attachment with a synthetic login. It did not use the default Chrome profile, the extension or a real account. A separate attempt with an explicit CDP URL was rejected by the active network policy. The successful host-local attachment preserved that policy. See what an agent does with its tools and why a search result cannot verify tab state for the evidence each tool can return. If you already have an authorized Tabbit session, compare the connection you need and the evidence it can return. Tabbit and OpenClaw
FAQ
Why does OpenClaw open a separate browser?
The managed openclaw profile has its own browser data directory, so it starts apart from your daily browser and its sign-ins.
Can OpenClaw use a signed-in browser session?
Yes, with an authorized existing-session or extension connection and a compatible browser. Verify the account and tab before using it.
Is a named OpenClaw profile the same as a Chrome profile?
It is a routing configuration. Two names can still target the same browser profile, so verify the actual storage or target when you need isolation.
Why does the user profile show no tabs?
Check which host and browser profile are selected, whether a tab is open, and whether the existing-session permission was accepted.
How do I end a browser task safely?
Close the test tab you created. Stop a managed browser only if you own that instance. Preserve pre-existing user tabs and release the attachment.