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.
Comments
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!
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.
Thanks for the quick response!
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.
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!
Yes you're going for it! Gogogog