Show HN: We packaged an MCP server inside Chromium
github.comwas freaking cool
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. ```
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.
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!