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.
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!
Thank you!
> 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?
Thanks for the quick response!
> 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!
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.
https://gemini.google/overview/gemini-in-chrome/
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)
See if this works for you https://github.com/eyalzh/browser-control-mcp
I see. Let me know if I got it correctly: if the UI of our browser looked different than Chrome, you would use that?
We kept the UI same because we felt people tend to have affinity towards using something they are familiar with.
> unlike chrome-devtools-mcp which starts a fresh headless instance each time
I'm pretty sure chrome-devtools-mcp can connect to a running instance: https://developer.chrome.com/docs/devtools/remote-debugging/...
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.
``` [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. ```
i vibe coded an HN clone in nextjs using this mcp server + claude code under 5 mins - https://dub.sh/yBOjNyL
was freaking cool
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!
haha fair point. but here you can clone any website's design as inspiration to build on top of it
In what way is this different than Playwright MCP?
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.
You can load use profiles, cookies and more during startup and get the logged in sessions.