--- id: "80a5d159-5117-445f-9f3c-d1dc7cab0aab" name: "Browser Connections" micro_summary: "Use local Chrome by default; diagnose with --doctor, and use named cloud daemons for isolation when warranted." status: "resolved" see_also: [] scope: "Current local and Browser Use cloud connection workflows, diagnostics, authentication, isolation choices, and remote-daemon lifecycle." --- ## 2026-08-15 — local and remote browser contract Local Chrome is the normal path. Run `browser-harness --doctor` for install, daemon, or connection failures. If Chrome is running without remote debugging, the harness opens `chrome://inspect/#remote-debugging`; ask the user to allow remote debugging and retry once rather than looping through permission popups. Cloud browsers are appropriate for isolated concurrent tasks, headless operation, or likely bot blocking. Authenticate with `browser-harness auth login` (or pipe a key to `auth login --api-key-stdin` without printing it), create a short named daemon with `start_remote_daemon(name)`, and use that same name through `BU_NAME` for all task calls. Do not fall back silently to the default daemon. A cloud daemon bills until stopped or timed out, so ask whether to close it when work ends and call `stop_remote_daemon(name)` on approval. --- ### 2026-09-01 23:29 UTC ## Connection recovery details The supported connection surfaces are the default local daemon, `BU_NAME`, `BU_CDP_URL`, `BU_CDP_WS`, and `start_remote_daemon(...)`. `BU_CDP_URL` is an HTTP DevTools endpoint; the daemon resolves it to WebSocket. On macOS, when Chrome shows the remote-debugging approval prompt, run `browser-harness mac-approve`; do not poll because the daemon holds one connection. Diagnose general failures with `browser-harness --doctor`. For installation or recovery beyond the local diagnostics, use `https://github.com/browser-use/browser-harness/blob/main/install.md`. Ask before leaving cloud browsers running and stop an approved target with `stop_remote_daemon(name)` or `PATCH /browsers/{id} {"action":"stop"}`.