dsh Browser Control: a text-only bridge between DeepSeek Harness and your real Chrome tabs

What dsh Browser Control actually connects

The project is one pnpm workspace holding two things that have to be installed together: a dsh bridge plugin under packages/browser/bridge-browser and an MV3 browser extension under extensions/dsh-browser. The bridge plugin is what DeepSeek Harness loads. The extension is what talks to Chrome or Firefox. Neither half is useful alone, which is why the README states plainly that the standard dsh plugin command cannot install this project.

The target user is someone already running DeepSeek Harness who wants the agent to act inside the browser profile they are logged into. Not a fresh automation profile, not a headless Chromium. The README frames the whole design around this: the model works in the page you already have open, retaining logins, sessions, and cookies. If your task is scraping a public site at scale, this is the wrong shape of tool, because it is bound to one user-controlled tab rather than a pool of disposable contexts.

Numbered controls instead of screenshots

The mechanism is a text snapshot. browser_snapshot returns the page title, URL, main text, and a numbered inventory of interactive elements. The model then addresses elements by that number, so browser_click takes an inventory number rather than a coordinate or a selector. The README notes that IDs are stable across snapshots and that delta: true returns only what changed, which matters because a full snapshot of a long page is a lot of tokens to resend on every step.

Form fields come back masked. Passwords and payment-card values are rendered as bullets and, per the README, never leave the page. That is a real boundary, not a marketing line: it means the model cannot read a credential even if a prompt injection in the page asks it to. The trade-off is that the agent also cannot verify what it typed into a password field, so a failed login looks the same as a successful one until the next snapshot shows the post-login page.

Browser tools never capture screenshots, and the README separates that page channel from dsh's multimodal message path. The side panel accepts PNG, JPEG, WebP, and GIF attachments when the host advertises image support, but those images come from you, not from the page.

Installing dsh Browser Control and running a first task

Requirements are Node.js ^22.19 or >=24, Corepack or pnpm, and Chrome 116+ or Firefox 140+. Windows additionally needs Windows PowerShell 5.1 or PowerShell 7+. The workspace pins dsh 0.1.5-rc.2 as the minimum supported runtime, and the README states that older DSH releases are not supported.

The one-line installer currently sets up the Chrome build. On macOS and Linux:

curl -fsSL https://raw.githubusercontent.com/Lum1104/dsh-browser/refs/heads/main/scripts/install.sh | bash

On Windows, from PowerShell:

$s="$env:TEMP\dsh-install.ps1"; irm https://raw.githubusercontent.com/Lum1104/dsh-browser/refs/heads/main/scripts/install.ps1 -OutFile $s; powershell -NoProfile -ExecutionPolicy Bypass -File $s

The installer downloads main, builds and registers the bridge plugin, builds the Chrome extension into ~/.dsh/browser-extension, and opens chrome://extensions. On a first install you load that directory as an unpacked extension and confirm dsh Browser Assistant appears. If dsh is already running, restart it after installation so the bridge plugin is picked up.

From the repository root, the build and start scripts are:

pnpm install
pnpm build
pnpm start

pnpm build compiles the bridge plugin and then the extension; pnpm start runs dsh web. Once the side panel is open, ask the agent to read the current tab. The first tool call you should see is browser_snapshot returning a title, a URL, and a numbered list of controls.

The pinned release candidate is the sharpest edge

The workspace depends on @deepseek-ai/dsh at 0.1.5-rc.2, alongside roughly twenty other @deepseek-ai/dsh-* packages at the same version. That is a release candidate, and the README calls it the minimum supported runtime rather than a recommended one. Anyone who tracks dsh main, or who is still on a 0.1.4 line, is outside the supported window.

This is a deliberate coupling and it has a cost. A plugin that binds to a harness's internal package set inherits every breaking change in that set. The repository ships scripts/check-runtime.mjs and scripts/smoke-runtime.mjs, which suggests the maintainers expect runtime mismatches to be a common failure and want them caught before a build rather than during a session. If you cannot upgrade dsh on the schedule this project follows, the extension will drift out of compatibility and the failure will look like a broken tool call, not a version error.

The second edge is packaging. The README warns that the unscoped dsh-browser package on npm belongs to a different project and is not affiliated with this repository, and that this project is not currently published as an npm package. Installing from the registry gets you someone else's code.

How it compares with Playwright-driven automation

The obvious alternative is driving the same browser through Playwright. The difference is where the browser context comes from. Playwright typically launches its own browser or connects over CDP to one you started with remote debugging, and the agent's actions are expressed as selectors or coordinates in a script. dsh Browser Control skips the launch step entirely: the extension attaches to tabs in the browser you already have open, and the model addresses numbered elements from a snapshot instead of writing selectors.

The project's own benchmark claims a gap. In a paired 60-run end-to-end benchmark dated August 18, 2026, both backends completed all 30 assigned runs, and the README reports mean end-to-end latency of 5.32 s for dsh Browser Control against 6.67 s for a matched Playwright baseline, with 3.4 browser tool calls against 4.7. That is the project's measurement of its own tool, on six browser tasks with the deepseek-v4-flash model, and the methodology and reproduction guide live in benchmark/README.md. Treat it as a claim with a reproduction path, not as an independent result.

The practical split: Playwright gives you deterministic replay, parallel contexts, and a test runner. dsh Browser Control gives you the logged-in session you already have and a conversation as the control surface. For a one-off task on a site behind a login, the second is far less setup. For a regression suite you run nightly, the first is the right tool and this project is not competing for that job.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, with Yuxiang Lin listed as author in package.json. MIT is permissive, so embedding the bridge plugin in an internal tool is straightforward. The one thing worth flagging is the dependency set: the MIT licence on this repository says nothing about the terms of the @deepseek-ai/dsh-* packages it pulls in, so if you redistribute a bundle, check those separately. That is a question for your own review, not something the README answers.

The last push was on 2026-09-13 and the repository is not archived. Two releases are listed: v0.1.1 on 2026-08-21 and v0.1.3 on 2026-09-04, whose notes mention Firefox, cross-platform setup, and contextual sessions. The package.json version is 0.1.4, which is ahead of the most recent tagged release, so main carries work that has not been tagged.

Upgrade cost is dominated by the pinned runtime. The installer downloads main each time it runs, so re-running it is the documented update path, but that also means you are always tracking the tip of main rather than a tag. If you need reproducible installs, pin the commit yourself; the README does not document a rollback path for a bad upgrade.

Editorial conclusion

Adopt dsh Browser Control if you run DeepSeek Harness 0.1.5-rc.2 or newer and want the agent working inside your logged-in browser rather than a headless copy. Do not adopt it if you need screenshots, canvas or WebGL interaction, or a stable pinned runtime, since the workspace pins a release candidate. Before installing, confirm your Node version matches the documented range, remember that the published dsh-browser npm package is a different project, and check whether your dsh instance needs restarting after the bridge plugin is registered.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Lum1104/dsh-browser on GitHub
4. README
5. Releases