A sandboxed browser has to replay a login, and the sites worth automating are exactly the ones that fight that — device checks, second factors, session cookies tied to an address. Driving the browser you already have makes that whole class of failure disappear, and the trade is the plain one: the automation runs in your session, on your machine, with everything that session can already reach.
A browser-automation server that never launches a browser of its own. A local bridge connects your running Chrome to a relay over the DevTools Protocol, and the endpoint drives that session, so pages behind a login, a saved passkey or a device the site already trusts behave the way they do when you use them yourself. Navigation and clicks return a read of the page layout along with the action, and you can keep several named Chrome profiles connected at once — personal, work, social — addressing whichever one you mean on each call. The relay, bridge, web UI, agent packaging and deployment code are in the open repository; the page-extraction engine runs behind a documented boundary in a private one.
- Navigation, clicks, typing and JavaScript evaluation against the Chrome session you are already signed into
- A page-layout read returned with the navigation or click itself, plus targeted reads: visible text, a search for a phrase, or the element at a coordinate with its link, classes, text and aria attributes
- A fingerprint of an unfamiliar single-page app that ranks which extraction approach is likely to work on it
- A file set on a page's file input, for uploads that would otherwise need a hand on the keyboard
- Several Chrome profiles connected under one key, each with its own cookies, sessions and extensions, addressed by name
- A throwaway Chrome launched from a copy of one of your profiles for a sign-in flow, with its popup tabs discoverable and individually addressable, and a cleanup call when the flow is finished