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
Use Tabbit CLI when the local agent needs the Tabbit session
OpenClaw's browser tool and Tabbit CLI are separate routes. OpenClaw's tool is supplied by its browser plugin and runs through the Gateway's browser control service. Its selected profile and target may be the Gateway host, a connected node, or a sandbox browser. A node route belongs on the machine that has the browser; sandboxed agents need the host-control policy before they can target it. OpenClaw browser routing Remote and hosted browsers
Tabbit CLI is useful when the agent process itself runs on a machine that can reach the intended Tabbit instance. Give that local runtime the Tabbit skill instructions and permission to run the installed launcher. In the default OpenClaw state, ~/.agents/skills/ is a personal skill root, so a same-user local Gateway agent can discover a Tabbit skill there. A different Gateway user, a custom OPENCLAW_STATE_DIR, an agent skill allowlist or a sandbox can change that. A node-hosted agent needs the skill on that node and the node must publish it while connected. Discovery is still separate from permission to execute a shell command. Confirm the shell's tabbit-cli launcher path, exec policy, selected Tabbit instance and website sign-in independently. OpenClaw skill locations OpenClaw node skills Tabbit CLI guide
Use a read-only task to triage a ticket queue. The prompt below asks for a named draft, not a ticket update. A separate task tab lets you continue working in your ordinary Tabbit window.
Use the installed Tabbit skill and Tabbit CLI from this local OpenClaw runtime. Start a named task with a fresh request ID, for example `nodejs --task "Ticket queue triage" --request-id ticket-queue-triage-20261109-01`, through the installed launcher. Do not add `--group`. Open the authorized ticket queue in a separate task tab. Read only tickets assigned to the test team that are marked open. Return a draft named "Ticket queue triage — draft 01" with ticket ID, visible title, current status, last-updated date, and source URL. Omit requester names, email addresses, message bodies, and other personal data. Do not change ticket fields, add comments, send messages, or close tickets. Stop and show the draft and source links for review. If the skill is unavailable, the launcher cannot reach Tabbit, or the page is signed out, report which check failed and stop.Before trusting the result, confirm three things: OpenClaw loaded the intended skill, its local shell can execute the Tabbit launcher, and the selected Tabbit browser is already signed in to the approved workspace. A successful openclaw browser call only verifies OpenClaw's chosen browser route; it does not prove that the local shell task used the same profile. See browser MCP and CLI connections for the difference.
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.