Choosing the Operating Boundary: Local, Remote, or Through DSH
BrowserSkill can be used locally, from a sandboxed agent that shares a host daemon, remotely through a paired server, or through a DeepSeek Harness plugin. These options expose the same browser-control model, but they do not create the same trust or operational boundary. This chapter compares them by daemon location, browser-profile authority, session ownership, cleanup, evidence, and capability limits so a reader can choose an operating arrangement rather than choosing by feature count.
Where the daemon lives changes the boundary
Local mode is the simplest arrangement when the agent and browser run on the same computer. The CLI reaches a daemon through local IPC, and the browser extension connects to the daemon over the local loopback path. The browser profile stays on the user's machine, and the main operational questions are whether the extension is connected, whether the session owns its Agent Window and tabs, and whether the daemon remains alive for the duration of the task. For ordinary local use, BrowserSkill can start the daemon automatically, which reduces setup friction but does not change the session and tab rules.
A sandboxed agent creates a process-lifetime problem rather than a new browser-permission model. Some command environments terminate child processes after each shell call. If the daemon is launched inside that shell, the next invocation may find no endpoint even though the browser and extension are ready. The solution is to keep the daemon in a persistent host context and let sandboxed commands reach the same BSK_HOME and IPC endpoint. Clients disable implicit startup with BSK_AUTO_START=0, check the existing daemon, and reuse it if it is healthy. An empty browser list after a successful status call means the daemon is reachable but no extension is connected; it is not evidence that a second daemon should be launched.
This arrangement adds a useful operational discipline. The host owns the daemon's runtime files and process lifetime. The sandbox owns individual CLI calls. A session stop belongs to the browser task and should leave the shared daemon alone. If the two environments do not see the same underlying directory, the client may diagnose the wrong daemon state. If permissions or IPC mounts are wrong, starting another daemon can obscure the original problem. The sandbox guide's emphasis on exact paths, persistent ownership, separate readiness checks, and bounded retries is therefore part of correctness, not merely deployment hygiene.
Remote mode changes where the powerful control path runs. The agent, CLI, and daemon can live on a server while the extension makes an outbound authenticated connection from the user's browser computer. The browser computer does not need an inbound listener, but the server now becomes part of the trust boundary around a browser profile that may contain signed-in sessions. Pairing is therefore device authorization, not a restricted account that can operate only inside one website.
The remote design adds protections appropriate to that boundary: one-use pairing links, device credentials, renewal and revocation, WSS for non-loopback connections, capacity and rate limits, and private daemon state. A device identity is bound to the authenticated connection rather than accepted from a self-reported browser identifier. Revocation can close existing connections and reject new ones. These mechanisms answer “which device may connect?” They do not answer every question about “which tab may this task control?” Remote content reads, screenshots, recording, and page operations still require that the task created or explicitly borrowed the target tab. A paired server can be authenticated and still be pointed at an unauthorized user tab.
The remote trust trade-off is therefore conditional.