--- title: "Browser use is a profile-scoped managed Bot Browser" version: "zh" --- > Documentation Index > Fetch the complete documentation index at: https://botharness.ai/llms.txt > Use this file to discover all available pages before exploring further. # Browser use is a profile-scoped managed Bot Browser > Status: Accepted # Browser use is a profile-scoped managed Bot Browser BotHarness gives PersonaBots browser use through a **Bot Browser**: one browser per profile, launched and supervised by BotHarness with its own persistent browser profile of cookies and sign-ins, shared by the PersonaBots as owned windows and tabs (ADR-0091). It is not the Human's everyday browser, and 1.0 ships no browser extension. The binary is preferably the Chrome or Edge already installed on the machine, launched with a dedicated `--user-data-dir` and a loopback CDP endpoint — which also sidesteps Chrome's restriction on debugging the default profile — and with the AutomationControlled blink feature disabled so `navigator.webdriver` stays false and the Human can sign in on sites that reject automated browsers; when no suitable browser is installed, a version-pinned Chrome for Testing is installed on demand. It is headed by default — the Human can see it, sign in once through the entry's **Open Bot Browser** action, and operate it directly — with a setting for headless. The capability ships as an optional standalone bundle, `@botharness/browser`, and owns the whole integration through a BotHarness-owned, application-defined provider: binary discovery and pinning, launch and supervision, the CDP driver, the persistent profile directory under `$DSH_HOME/botharness/browser`, and the sign-in flow. It does not depend on the experimental `@deepseek-ai/dsh-browser-use` service or provider packages: that seam only reserves a provider name, is not composed by default, and would add an experimental dependency for no capability. The Bot Browser starts on first use, stops after the same 30-minute idle window as the Computer, logs launch, stop, and refusals to `logs.db`, and a stopped browser is a readable tool-call error that never threatens Host boot. Container execution is the same mechanism (Chromium plus CDP on a loopback port) and is deferred; a remote viewer's explicit enable-interaction control belongs to that deferred target rather than the local Pause Bot control (ADR-0090). Only the local target ships first, mirroring ADR-0082's sequencing. ## Why - One shared browser with independent tabs keeps multi-Bot work cheap and parallel: no per-PersonaBot browser instance (one Chromium per Bot was already a hard ~200–230 MB constraint in ADR-0083), and background CDP targets act without taking the foreground, so tabs replace the sequential desktop-workspace model. - Driving the Human's everyday browser is not reliably available: Chrome restricts remote debugging on default profiles, and the extension route carries a developer-mode and policy lifecycle — Chrome removed `--load-extension` and can disable unpacked extensions — plus an all-sites debugger grant, a "started debugging this browser" infobar, and manual reloads for updates. The managed browser is the Computer's shape applied to browsing: a profile-scoped shared resource with per-PersonaBot access, session authorization, audit, and a viewer. - Preferring the installed Chrome keeps the binary maintained by the browser's own updater, with a real brand and fingerprint; the fallback installs a version-pinned Chrome for Testing for machines without Chrome, so the Host is never blocked on a missing browser. - The costs are accepted explicitly: the Human signs in once inside the Bot Browser instead of inheriting current daily-browser sessions, and anti-automation checks on some sites remain a known limitation. ## Considered options - **Extension bridge to the Human's browser (BrowserSkill-style borrow/return)** — deferred: strongest login reuse, but a new distribution and trust line (developer-mode sideload, Chrome policy, debugger infobar, DevTools conflicts) that 1.0 deliberately does not take on; revisit only if using the Human's current sessions becomes a hard requirement. - **Official experimental browser-use service and providers** — rejected: experimental channel, not composed by default, a single global slot with whole-Host activation, and a tool catalog we do not own. - **Attach to the already-running Chrome over CDP** — rejected: requires relaunching the Human's browser with debugging flags; not a user-installable default. - **Per-PersonaBot browser instances** — rejected: repeats ADR-0083's memory constraint for no additional capability; tabs already give independent work surfaces. - **Folding Browser into `@botharness/computer`** — rejected: Browser is an independent capability with its own access switch, tools, audit, and surfaces; the optional-bundle pattern of ADR-0050 keeps "not installed means not there". ## Consequences - The bundle owns binary discovery and pinning, launch policy, the CDP driver, the persistent profile, and sign-in; browser-profile backup and export stay a later profile-level decision, like Computer Export. - Browser Access, Authorization, Audit, and Pause land per ADR-0090; per-Bot window and tab scoping per ADR-0091. - Delivery starts with a read-only browsing slice — open, semantic observe, screenshot — carrying the full access, authorization, audit, and observation plumbing; interaction tools follow. - If DSH's browser-use seam stabilizes, registering this provider's name on it is a local change; the tool surface and Consumers stay. Source: https://botharness.ai/zh/dev/adr/0089-browser-use-is-a-profile-scoped-managed-bot-browser/index.mdx