Browser-use's Real Risk Surface Is the Browser Session

The first browser-use test should not be “can the agent click the button?” It should be “what exactly did the agent get permission to see, change, and reuse?” The project has three different surfaces: the Python library (Agent, Browser, ChatBrowserUse), Browser Use CLI 2.0 for coding agents, and the lower-level Actor API (BrowserSession, Page, Element, Mouse). CLI 2.0 uses a persistent daemon and direct Chrome DevTools Protocol communication. That can reduce orchestration overhead, but it also makes the daemon socket, session history, browser profile, and local process permissions part of the security review. My first run is deliberately boring: python -m venv .venv source .venv/bin/activate pip install browser-use python -c "from browser_use import Agent, Browser, ChatBrowserUse; print('imports ok')" Enter fullscreen mode Exit fullscreen mode Then I use a disposable profile and a test account for one read-only navigation. I keep the final URL, page title, model output, and any file or JavaScript action as evidence. A page opening is not proof of task correctness. The version boundary matters. The manual records that v0.12.5 stopped installing litellm as a core dependency after a supply-chain incident. v0.12.8 added owner-only Unix socket permissions and refused evaluate() on restricted browser profiles. A copied tutorial that says “install everything and reuse Chrome” is hiding two decisions you still need to make. The useful failure split is also concrete: blank Chromium can be a missing key or wrong model; stale imports are a documentation/version problem; Ollama empty structured output is a model compatibility problem; canvas hover may require a different action surface. Treating all of those as “browser automation is flaky” loses the diagnosis. Manual: https://doramagic.ai/en/projects/browser-use/manual/