Hacker News Reader

Comment by vebgen | Hacker News Reader

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!

View on HN

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!

Yes you're going for it! Gogogog

Reply on news.ycombinator.com