Congrats on the launch! The embedded MCP server approach is clever.
Quick question about session handling: how do you manage auth
state conflicts when multiple agents interact with the same
logged-in session simultaneously? We're building an AI agent
for Django development and ran into similar challenges with
managing concurrent operations in a sandbox environment.
Also curious about your anti-bot detection implementation at
the C++ level. Are you modifying specific Chromium fingerprinting
APIs or taking a different approach?
Checking out the repo now — love that it's open source!
> curious about your anti-bot detection implementation at the C++ level. Are you modifying specific Chromium fingerprinting.
TLDR basically most browser automation platforms use CDP or CDP based APIs and websites are able to detect it as bots. We built new C++ APIs into rendering engine for type, click, extract which are not CDP based and surprisingly don't get detected by most websites.
> auth states
I'm not fully sure I understand the issue here. Are you referring to same web app but tasks require different user-logins?
That's brilliant - bypassing CDP entirely is the right call. Most anti-bot
systems specifically look for navigator.webdriver and CDP artifacts. Building
click/type primitives directly into the rendering pipeline is much cleaner.
> auth state question
Sorry, I wasn't clear! I was thinking about the scenario where you have
multiple MCP clients (say Claude Desktop + another agent) both trying to
control the same BrowserOS session. Do requests get queued, or can they
interleave?
For our Django agent sandbox, we handle it by serializing operations - only
one agent action at a time. Curious if you do something similar or if the
HTTP/WebSocket layer handles concurrency differently.
The architecture diagram showing WebSocket → Extension → Browser makes sense
now. Will definitely be trying this for testing our Django apps - the
logged-in session persistence would save tons of auth setup time.
I went back to Chrome after suffering bugs in BrowserOS, and Chrome recently added a powerful Gemini feature that does what I suggested to your team when you announced your product. I just could not derive any value from BrowserOS.
Ohh man, this definitely hurts. We were a team of 2 until recently and we've been working hard to get through the backlog of feature requests as fast as possible.
I think we've definitely improved the product a lot since we launched, you should try it out!
The BrowserOS-as-MCP server we believe is a nice useful + differentiated feature that other browsers don't have. You can use BrowserOS with claude-code, claude-desktop or gemini-cli for many useful things!
I personally wasn't a fan of having something so similar to chrome. I hate chrome so chrome + ai just wasn't what I was looking for.
Currently using orion on mac, and despite it's buggyness, its still got features/layout/design/extensions that I prefer to run currently. (Specific extension support being a big one)
Hmm I've tried. Google chrome doesn't allow starting `--remote-debugging-port` on main profiles. Logs below from my MacOS. not sure if it allows on other OSes.
No resulting code, just a page rendered similarly. I could save you those 5 mins: just open any site and hit Ctrl+u, Ctrl+a, ctrl-c - done, you now have vibecoded a clone of any site to your clipboard!
good question. key difference is MCP server is built right into the browser and works with your logged sessions. One-click to connect, no CDP setup needed. Also supports multiple parallel connections via MCP http transport.
Quick question about session handling: how do you manage auth state conflicts when multiple agents interact with the same logged-in session simultaneously? We're building an AI agent for Django development and ran into similar challenges with managing concurrent operations in a sandbox environment.
Also curious about your anti-bot detection implementation at the C++ level. Are you modifying specific Chromium fingerprinting APIs or taking a different approach?
Checking out the repo now — love that it's open source!
> curious about your anti-bot detection implementation at the C++ level. Are you modifying specific Chromium fingerprinting.
TLDR basically most browser automation platforms use CDP or CDP based APIs and websites are able to detect it as bots. We built new C++ APIs into rendering engine for type, click, extract which are not CDP based and surprisingly don't get detected by most websites.
> auth states I'm not fully sure I understand the issue here. Are you referring to same web app but tasks require different user-logins?
> Non-CDP APIs at rendering engine level
That's brilliant - bypassing CDP entirely is the right call. Most anti-bot systems specifically look for navigator.webdriver and CDP artifacts. Building click/type primitives directly into the rendering pipeline is much cleaner.
> auth state question
Sorry, I wasn't clear! I was thinking about the scenario where you have multiple MCP clients (say Claude Desktop + another agent) both trying to control the same BrowserOS session. Do requests get queued, or can they interleave?
For our Django agent sandbox, we handle it by serializing operations - only one agent action at a time. Curious if you do something similar or if the HTTP/WebSocket layer handles concurrency differently.
The architecture diagram showing WebSocket → Extension → Browser makes sense now. Will definitely be trying this for testing our Django apps - the logged-in session persistence would save tons of auth setup time.
Excited to see where you take this!
https://gemini.google/overview/gemini-in-chrome/
I think we've definitely improved the product a lot since we launched, you should try it out!
The BrowserOS-as-MCP server we believe is a nice useful + differentiated feature that other browsers don't have. You can use BrowserOS with claude-code, claude-desktop or gemini-cli for many useful things!
We kept the UI same because we felt people tend to have affinity towards using something they are familiar with.
I'm pretty sure chrome-devtools-mcp can connect to a running instance: https://developer.chrome.com/docs/devtools/remote-debugging/...
``` [I] ~ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --enable-logging=stderr --remote-debugging-port=9445 (base) [27920:145785320:1017/131556.797325:INFO:components/enterprise/browser/controller/chrome_browser_cloud_management_controller.cc:206] No machine level policy manager exists.
DevTools remote debugging requires a non-default data directory. Specify this using --user-data-dir. ```
was freaking cool