3 ms·

Congrats on the launch! The embedded MCP server approach is clever. Quick question about session handling: how do you manage auth state conflicts when multipl

by vebgen 1y ago

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!

felarof 1y ago
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?
- vebgen 1y ago
  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!
- itsankur 11mo ago
  Yes you're going for it! Gogogog

by vebgen 1y ago

felarof 1y ago

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?

vebgen 1y ago
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!
itsankur 11mo ago
Yes you're going for it! Gogogog