v0.3.6 — dsh 0.2.1 compatibility, zero-config discovery

Fixed

• The bridge could not connect on dsh 0.2.1-rc.1 and later. dsh 0.2.1 tightened the PeerScope contract that TypertGateway.wireStream.open reads, and the bridge passed undefined for the Peer. The socket still completed its handshake — hello.ok arrived — and then the gateway-owned $events stream threw before delivering a single frame, so the server closed with WS 1011 and the extension retried forever. In the side panel this looked like a status flickering between connecting, connected, and reconnecting while the service worker's Network tab stayed empty.

  Three separate reads failed in sequence, which is why this took three fixes to clear: methodSignal joins every stream's signal with request.peer.signal; requireInteractions rejects a Peer whose interactions is not 'answer'; and openRemoteEvents stores peer.principal and reads principal.kind. The bridge now supplies one real in-process Peer satisfying all three.

  0.3.5 has the same defect, so upgrading along the old line would not have helped.

• The extension could not find the bridge after a DSH restart. DSH Desktop assigns its web port at random on every launch, and the extension cannot read the filesystem to learn the new one — so the only options were re-pasting the bridge URL by hand or probing a wide port range. The plugin now binds a fixed loopback port (30789-30791, first free one wins) and answers /ext/bridge-config with the live WebSocket URL. The extension tries it first: one request instead of a scan, which also removes the pattern that looks like port scanning to security software.

Changed

• The plugin has its own settings tab (settings.section) instead of a row inside General settings.
• The extension moves the bridge address and token under Advanced; on loopback the bridge is found automatically and no token is needed.

Install

dsh plugin --profile web add @dightendless/dsh-bridge-browser

Then restart DSH. The extension releases to ~/.dsh/browser-extension; load it once via chrome://extensions → Developer mode → Load unpacked.

Verification

typecheck clean · 508/508 tests across 58 files · check:runtime passing · real dsh 0.2.1-rc.1 handshake held open with zero error frames.

dsh-browser 0.3.5 — the bridge plugin and the extension

dsh-browser 0.3.5 — the bridge plugin and the extension

Two artifacts, same release:

• dightendless-dsh-bridge-browser-0.3.5.tgz — the DSH plugin (bridge-browser), prebuilt,
  with the extension bundled inside it.
• dsh-browser-extension-0.3.5.zip — the Chrome/Edge extension, already built, for the
  manual route. Unzip it, then load the folder through Load unpacked.

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.3.5/dightendless-dsh-bridge-browser-0.3.5.tgz

The plugin is also on npm — npm i @dightendless/dsh-bridge-browser — for setups that resolve
plugins from a registry rather than from a release asset.

What changed since 0.3.4

The author field was wrong, and this release fixes it.

Every manifest in this repository was inherited from the upstream project this fork came from,
and all of them still carried "author": "Yuxiang Lin". That is not a cosmetic string: it is
what npm prints on the package page, and it is what a catalog that reads the manifest displays
next to the plugin. The listing on deepseek.stream has therefore been crediting someone who has
nothing to do with this fork. It now reads DightEndless in the bridge package, the extension
package, and the workspace root.

LICENSE is deliberately untouched. It carries the upstream MIT copyright line, and the fork
has no standing to reassign it.

There is no code change in this release. No source file, no behaviour, no dependency. The
extension bytes are identical to 0.3.4 apart from the manifest version, and the plugin code is
identical. This release exists only to correct what a package page and a catalog listing say
about who wrote the plugin.

Do I need to upgrade?

• If you install from npm or from the release asset: only if the author attribution matters
  to you. Nothing about how it runs has changed, so staying on 0.3.4 costs you nothing
  functionally.
• If you already run the extension: you can leave it alone. The plugin ships the same
  extension build, and a second startup recognises the installed copy as current.
• A catalog entry only picks up a new manifest on its next edit. A manifest field is a
  snapshot taken when the entry is submitted, not a live reference, so a listing that shows the
  old author will keep showing it until that entry is edited.

Requirements

Chrome 116+ (or Edge); and DSH 0.2.0-rc.2 or newer within 0.2.x, including the 0.2.1-alpha
line. The source-installer route additionally needs Node.js 22+ with pnpm.

Three ways to install

1. Plugin from this release (one command, nothing to build) — the line above, or
   npm i @dightendless/dsh-bridge-browser. Then open the panel and follow the four steps to
   load the extension it just unpacked.
2. Extension only — download dsh-browser-extension-0.3.5.zip, unzip, then
   chrome://extensions → Load unpacked → pick the unzipped folder.
3. Everything from source — the installer in the README clones the repository, builds both
   halves and registers the plugin bundle.

Then open the side panel on any page and ask: the model sees a numbered inventory of what is on
screen and acts through those numbers.

dsh-browser 0.3.4 — the bridge plugin and the extension

dsh-browser 0.3.4 — the bridge plugin and the extension

Two artifacts, same release:

• dightendless-dsh-bridge-browser-0.3.4.tgz — the DSH plugin (bridge-browser), prebuilt,
  so no build step and no allowlisting are needed. It now carries the extension inside it.
• dsh-browser-extension-0.3.4.zip — the Chrome/Edge extension, already built, for the
  manual route. Unzip it, then load the folder through Load unpacked.

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.3.4/dightendless-dsh-bridge-browser-0.3.4.tgz

The plugin is also on npm — npm i @dightendless/dsh-bridge-browser — for setups that resolve
plugins from a registry rather than from a release asset.

What changed since 0.3.3

Installing is now one command, one restart, and one click.

Adding the plugin used to be half the job: the browser extension was not in the package, so
after installing you still had to come back here, download the zip, unzip it somewhere sensible,
and pick that folder in chrome://extensions. The plugin now ships the built extension and
releases it to ~/.dsh/browser-extension the first time it starts. The side panel shows the
four steps and copies the directory path for you, so what is left is a single Load unpacked.

It is safe to install over an older plugin:

• A second startup does nothing — the installed version is compared with the bundled one.
• Upgrading re-copies the extension and removes files the new version no longer has.
• If the directory cannot be written (a read-only home, for instance), the plugin keeps working
  and the panel falls back to showing the path inside the package, with the reason.

Do I need the new extension zip?

Not for this release. The extension code is unchanged: dsh-browser-extension-0.3.4.zip differs
from 0.3.3 in exactly two files — manifest.json (the version) and build-stamp.json (the build
metadata) — with every script and asset byte-identical. If you already run the 0.3.3 extension you
can leave it alone; installing the 0.3.4 plugin hands you a copy of the same build.

Requirements

Chrome 116+ (or Edge); and DSH 0.2.0-rc.2 or newer within 0.2.x, including the 0.2.1-alpha
line. The source-installer route additionally needs Node.js 22+ with pnpm.

Three ways to install

1. Plugin from this release (one command, nothing to build) — the line above, or
   npm i @dightendless/dsh-bridge-browser. Then open the panel and follow the four steps to
   load the extension it just unpacked.
2. Extension only — download dsh-browser-extension-0.3.4.zip, unzip, then
   chrome://extensions → Load unpacked → pick the unzipped folder.
3. Everything from source — the installer in the README clones the repository, builds both
   halves and registers the plugin bundle.

Then open the side panel on any page and ask: the model sees a numbered inventory of what is on
screen and acts through those numbers.

dsh-browser 0.3.3 — the bridge plugin and the extension

dsh-browser 0.3.3 — the bridge plugin and the extension

Two artifacts, same release:

• dightendless-dsh-bridge-browser-0.3.3.tgz — the DSH plugin (bridge-browser),
  prebuilt, so no build step and no allowlisting are needed.
• dsh-browser-extension-0.3.3.zip — the Chrome/Edge extension, already built.
  Unzip it, then load the folder through Load unpacked.

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.3.3/dightendless-dsh-bridge-browser-0.3.3.tgz

The plugin is also on npm — npm i @dightendless/dsh-bridge-browser — for setups that
resolve plugins from a registry rather than from a release asset.

What changed since 0.3.2

This is the first release in which the extension itself changes. The 0.3.1 and 0.3.2
extension zips differed from their predecessors by the manifest version alone, so if you
installed either of them there was nothing to gain by reinstalling. This one is different:
if you are running the 0.3.2 plugin or older, update the extension too, or none of the
fixes below will reach you.

A page dialog no longer dead-ends the tab

alert, confirm, prompt and beforeunload freeze the tab's JavaScript thread, and the
content script that every browser tool goes through is part of what stops answering. The old
behaviour was a timeout — then a second, identical timeout from the tool the first message
pointed at.

The dialog is now reported while it is still cheap to do so, and answered by the model through
a new tool, browser_dialog:

[Native JS dialog opened: confirm("Delete this record?") — WARNING: Tab is frozen.
 Call browser_dialog with action: 'accept' or 'dismiss', or call browser_reload to abort.]

accept / dismiss, plus promptText for a prompt (an accepted prompt with no text submits
the page's own default). Nothing is answered on your behalf — the call goes through the
same approval prompt as every other state-changing tool, so you see the dialog's question and
the answer before it is sent. If nothing answers within 60 seconds the dialog can no longer be
answered at all; browser_reload then resets the tab.

Controls that were visible but unreachable

A checkbox or radio made invisible the usual way — opacity: 0, or a zero-sized input behind
a styled label, as every component library does it — had no snapshot number of its own, so the
model could read it but never click it. Its visible label is now indexed as the proxy:

[4] checkbox "Custom Styled Switch (via label)"

Clicking or toggling that number drives the real input. Two related gaps are closed in the same
pass: browser_click_at now sends a pointer move first, so a control that ignores a click until
it has seen a hover responds; and an element outside the viewport is scrolled into view,
re-measured, and clicked only once it really landed inside.

Reload is a real escape hatch

browser_reload used to be routed through the content script — the one channel a frozen tab
cannot answer — so the tool the error message recommended was the tool that would fail next.
It now falls back to the browser-level reload, which resets the page in milliseconds. That
makes it the way out of any frozen tab, dialog or not.

Requirements

Chrome 116+ (or Edge); and DSH 0.2.0-rc.2 or newer within 0.2.x, including the 0.2.1-alpha
line. The source-installer route additionally needs Node.js 22+ with pnpm.

Three ways to install

1. Plugin from this release (one command, nothing to build) — the line above, or
   npm i @dightendless/dsh-bridge-browser.
2. Extension only — download dsh-browser-extension-0.3.3.zip, unzip, then
   chrome://extensions → Load unpacked → pick the unzipped folder.
3. Everything from source — the installer in the README clones the repository, builds both
   halves and registers the plugin bundle.

Then open the side panel on any page and ask: the model sees a numbered inventory of what is on
screen and acts through those numbers.

dsh-browser 0.3.2 — the bridge plugin and the extension

dsh-browser 0.3.2 — the bridge plugin and the extension

Two artifacts, same release:

• dightendless-dsh-bridge-browser-0.3.2.tgz — the DSH plugin (bridge-browser),
  prebuilt, so no build step and no allowlisting are needed.
• dsh-browser-extension-0.3.2.zip — the Chrome/Edge extension, already built.
  Unzip it, then load the folder through Load unpacked.

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.3.2/dightendless-dsh-bridge-browser-0.3.2.tgz

The plugin is also on npm — npm i @dightendless/dsh-bridge-browser — for setups that
resolve plugins from a registry rather than from a release asset.

What changed since 0.3.0

The package installs on a DSH 0.2.1-alpha host. 0.2.0-rc.2 hosts worked, but a
0.2.1-alpha.1 host — the build the plugin marketplace states it verifies against — failed
the peer check before the plugin ever loaded:

• every @deepseek-ai/dsh-* peer was pinned to exactly 0.2.0-rc.2. The ranges now read
  0.2.0-rc.2 || >=0.2.1-alpha.1 <0.3.0. A broad "minimum version" would not have done it:
  npm does not let a prerelease satisfy a range unless that range names a prerelease itself.
• @deepseek-ai/cordis was left at ~4.0.4 in 0.3.1, and that alone kept the install
  broken — every 0.2.1-alpha.1 package declares peer @deepseek-ai/cordis@~4.0.5-alpha.1,
  so npm resolved cordis down to 4.0.4 and then failed with ERESOLVE. The range is now
  ~4.0.4 || ~4.0.5-alpha.1.
• @deepseek-ai/dsh-invariants is an optional peer: it has no 0.2.1-alpha.*
  publication at all, and this package imports only its types — the companion plugin carries
  inject: ['invariants'], so a host without that service never mounts it.

The 0.3.1 tarball already carried the dsh-* ranges; 0.3.2 exists because 0.3.1 was
published twenty minutes earlier and npm versions are immutable. The cordis gap was found by
installing the published 0.3.1 tarball next to the alpha peer set in an empty project, which
is also the check that now passes for 0.3.2.

The READMEs name npm beside the release tarball, in both languages.

No extension behaviour changed in either release: the zip differs from 0.3.0 by its manifest
version alone.

Requirements

Chrome 116+ (or Edge); DSH 0.2.0-rc.2 or newer within 0.2.x, including the 0.2.1-alpha
line; and, for the installer route only, Node.js 22+ with pnpm.

Checked on a real 0.2.1-alpha.1 host (2026-10-11): a clean DSH_HOME
plus npx @deepseek-ai/dsh@0.2.1-alpha.1 web composed this bundle, the plugin wrote its boot-time ext-bridge-token, and a WebSocket handshake to /ext/bridge completed before the bridge closed it with code 1008 for a malformed first frame. Re-run it yourself; the marketplace's own verification is still the record that counts.

Three ways to install

1. Plugin from this release (one command, nothing to build) — the line above, or
   npm i @dightendless/dsh-bridge-browser.
2. Extension only — download dsh-browser-extension-0.3.2.zip, unzip, then
   chrome://extensions → Load unpacked → pick the unzipped folder.
3. Everything from source — the installer in the README clones the repository, builds
   both halves and registers the plugin bundle.

Then open the side panel on any page and ask: the model sees a numbered inventory of what is
on screen and acts through those numbers.

dsh-browser 0.3.1 — the bridge plugin and the extension

dsh-browser 0.3.1 — the bridge plugin and the extension

Two artifacts, same release:

• dightendless-dsh-bridge-browser-0.3.1.tgz — the DSH plugin (bridge-browser),
  prebuilt, so no build step and no allowlisting are needed.
• dsh-browser-extension-0.3.1.zip — the Chrome/Edge extension, already built.
  Unzip it, then load the folder through Load unpacked.

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.3.1/dightendless-dsh-bridge-browser-0.3.1.tgz

The plugin is also on npm — npm i @dightendless/dsh-bridge-browser — for setups that
resolve plugins from a registry rather than from a release asset.

What changed since 0.3.0

The package installs on a DSH 0.2.1-alpha host now. Every @deepseek-ai/dsh-* peer was
pinned to exactly 0.2.0-rc.2, so on a 0.2.1-alpha.1 host — the build the plugin
marketplace states it verifies against — the peer check failed before the plugin ever loaded.
The peers are now 0.2.0-rc.2 || >=0.2.1-alpha.1 <0.3.0, which makes both the rc line this
tree develops against and the alpha line it is verified against explicit. A broad
"minimum version" range would not have done it: npm does not let a prerelease satisfy a
range unless that range names a prerelease itself.

@deepseek-ai/dsh-invariants is an optional peer. It has no 0.2.1-alpha.* publication
at all (latest is 0.0.1-rc.1), and this package only imports its types: the companion
plugin carries inject: ['invariants'], so a host without that service never mounts it.

The READMEs name npm beside the release tarball, in both languages.

No extension behaviour changed in this release: the zip differs from 0.3.0 by its manifest
version alone.

Requirements

Chrome 116+ (or Edge); DSH 0.2.0-rc.2 or newer within 0.2.x — the published package's
peer ranges accept the 0.2.1-alpha line as well — and, for the installer route only,
Node.js 22+ with pnpm.

Removing the install-time blocker is not by itself proof that the plugin loads on a
0.2.1-alpha.1 host; that check belongs to the marketplace's own verification run, and its
result is recorded on the entry, not here.

Three ways to install

1. Plugin from this release (one command, nothing to build) — the line above, or
   npm i @dightendless/dsh-bridge-browser.
2. Extension only — download dsh-browser-extension-0.3.1.zip, unzip, then
   chrome://extensions → Load unpacked → pick the unzipped folder.
3. Everything from source — the installer in the README clones the repository, builds
   both halves and registers the plugin bundle.

Then open the side panel on any page and ask: the model sees a numbered inventory of what is
on screen and acts through those numbers.

dsh-browser 0.3.0 — registry-based index resolution, reload-safe content script

dsh-browser 0.3.0 — the bridge plugin and the extension

Two artifacts, same release:

• dightendless-dsh-bridge-browser-0.3.0.tgz — the DSH plugin (bridge-browser),
  prebuilt, so no build step and no allowlisting are needed.
• dsh-browser-extension-0.3.0.zip — the Chrome/Edge extension, already built.
  Unzip it, then load the folder through Load unpacked.

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.3.0/dightendless-dsh-bridge-browser-0.3.0.tgz

What changed since 0.2.0

A page can no longer move the target of an approved click. browser_click_at,
browser_hover and browser_drag resolved a snapshot number through the
data-dsh-el attribute, which is a DOM attribute — any page script could read it,
move it, or invent one that querySelector finds first, and the point the user
approved would land somewhere else. The number now resolves through the content
script's element registry, which lives in the extension's isolated world where the
page has no reach. Verified live: with a forged data-dsh-el="1" planted at (6, 6)
ahead of the real element, the tool still acted on the real element at (831, 792).

Reloading the extension no longer litters the error list. The content script left
running in open tabs after a reload had a dead chrome.runtime, and calling into it
throws "Extension context invalidated" synchronously — a .catch() never saw it.
Every call out now checks the context first, and the selection watcher disposes itself
once it finds it has been orphaned.

browser_batch fails the call when a step fails. It used to answer ok with the
failure described in the text, so a broken batch read as a success in the harness and
in the panel while every other tool reported its own failure. The per-step report now
travels in the error message, so the model still sees which step failed and what the
page said.

The extension build stopped dropping files on non-ASCII paths. fs.cpSync to a
destination whose path holds non-ASCII characters crashed the process after the
bundles were written, which produced a dist folder that looked complete and was not.
The build now copies through a tested helper and asserts every path the manifest
references exists.

The package README was stale in the 0.2.0 tarball — it predated the fork's identity
work, so it still pointed its installer commands at the upstream repository. The 0.3.0
tarball carries the corrected README: fork disclosure, this repository's installers,
and the tool list that includes hover, coordinate clicks, drag, batches, whole-page
screenshots, upload, image addresses and multi-browser switching. The 0.2.0 asset was
also rebuilt in place, so its URL installs correctly too.

Requirements

Chrome 116+ (or Edge), DSH on the 0.2.0-rc.2 line or newer within 0.2.x, and —
only for the installer route — Node.js 22+ with pnpm.

Three ways to install

1. Plugin from this release (one command, nothing to build) — the line above.
2. Extension only — download dsh-browser-extension-0.3.0.zip, unzip, then
   chrome://extensions → Load unpacked → pick the unzipped folder.
3. Everything from source — the installer in the README clones the repository,
   builds both halves and registers the plugin bundle.

Then open the side panel on any page and ask: the model sees a numbered inventory of
what is on screen and acts through those numbers.

dsh-bridge-browser v0.2.0 (standalone fork)

DeepSeek Harness browser bridge — the plugin half of this fork.

What this is. @dightendless/dsh-bridge-browser drives the Chrome/Edge tab you
are already looking at: read the page as structured text, click, type, hover,
drag, batch, evaluate, upload, screenshot (viewport and full page), manage tabs.
It talks to the dsh-browser-extension in this same repository over a
token-authenticated WebSocket on loopback.

Install the plugin. This release carries the plugin as a prebuilt tarball,
so nothing is compiled on your machine:

dsh plugin --profile web add https://github.com/DightEndless/dsh-browser/releases/download/v0.2.0/dightendless-dsh-bridge-browser-0.2.0.tgz

Install the extension. The browser half is unpacked, because Chrome does not
let an unpacked extension be installed from a store. This release carries it
built, so no toolchain is needed either:

1. download dsh-browser-extension-0.3.0.zip and unzip it;
2. open chrome://extensions (Edge: edge://extensions) and turn on Developer mode;
3. choose Load unpacked and select the folder that came out of the zip.

Those two steps are the whole product: no Node, no pnpm, no Git.

Or install both halves with one command, which builds from source and
therefore needs Node.js 22+ and pnpm:

• Windows: $s="$env:TEMP\dsh-install.ps1"; irm https://raw.githubusercontent.com/DightEndless/dsh-browser/refs/heads/main/scripts/install.ps1 -OutFile $s; powershell -NoProfile -ExecutionPolicy Bypass -File $s
• macOS / Linux: curl -fsSL https://raw.githubusercontent.com/DightEndless/dsh-browser/refs/heads/main/scripts/install.sh | sh

The installer builds both halves, registers the bridge plugin, puts the
extension where the browser loads it from, and opens chrome://extensions.

Installing the plugin from repository source instead (github:DightEndless/dsh-browser#path:/packages/browser/bridge-browser)
also works, but the package builds itself on install and pnpm refuses to run
build scripts until it is allowlisted, so it takes an extra approval step.

Requirements. Chrome 116+ (or Edge), DSH on the 0.2.0-rc.2 line, and — for
the installer only — Node.js 22+ with pnpm.

Rebuilt asset (same day). dsh-browser-extension-0.3.0.zip was rebuilt after
this release first went up: an inventory number now resolves through the content
script's element registry, which lives where the page cannot reach it, instead of
through the page-writable data-dsh-el attribute. A page can no longer move the
point that browser_click_at / browser_hover / browser_drag act on. The file
name and its URL are unchanged.

Permissions. The extension asks for site access (that is what page reading
and clicking are) and, optionally, the debugger permission — hover, coordinate
clicks, drag, page-context evaluation, and the screenshot fallback all go through
the DevTools protocol. debugger is optional: it is requested the first time a
tool needs it, and while it is granted Chrome shows its own "being controlled"
banner.

License. MIT, from the upstream project omdsh-dev/dsh-browser.