Seems like it's based on Chromium? If so, that's a no-go for me. We need more web diversity and support smaller browser engines, we don't need yet another Chromium/Blink based browser.
I agree with this sentiment, but besides Webkit/Chromium and Firefox's Gecko, there's not really any options. Ladybird is a new implementation gaining fast though don't think it's ready to replace everyday workflows yet. And Ladybird has been a huge undertaking of course.
Building a new browser engine is 99% of the work and slapping LLM features on it is the other 1% of it.
> 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.
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!
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.
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.
There is an open source alternative -- browserOS.com