dshpluginsdev
DeepSeek Harness (DSH) web plugins, by DIV7NE.
Each plugin is a self-contained package in this repository. Every one of them
declares its own bundle patch, so installing a single directory is enough — the
DSH CLI appends it to the profile's bundle stack and no profile file is edited by
hand.
| Plugin | What it does |
|---|
dsh-suggest-next-prompt/ | Puts a model-generated next prompt in the chat composer's placeholder. Tab pastes it, ↑/↓ cycle the shortlist, Esc dismisses. |
dsh-chrome-agent/ | Drives your real, already logged-in Chrome through a pinned companion extension, instead of a separate browser profile. |
| dsh-run-in-terminal | A Run button on every chat code block, and an integrated terminal in the right sidebar to run it in. |
Installing a plugin
git clone https://github.com/DIV7NE/dshpluginsdev
cd dshpluginsdev/<plugin>
npm install
npm run install:profile # builds, packs, and installs into the web profile
Then restart the DSH server for that profile — a profile's bundle stack and
the browser's client-module graph are both composed at boot, so a new plugin
cannot appear in a running server. Once a plugin is in the graph, later changes
need only a page reload.
The Chrome extension
dsh-chrome-agent ships two artifacts from one directory, and they are released
separately:
- the DSH plugin (this repository's package, installed like its siblings);
- the Chrome extension, a plain folder under
dsh-chrome-agent/extension/
packed by scripts/pack-webstore.mjs into a root-level zip, which is the
artifact the Chrome Web Store uploads. It is built and attached to Releases,
not published through the DSH plugin channel.
npm run pack:webstore in that directory regenerates the zip. CI runs it and
asserts the zip still contains manifest.json at its root, because the plugin's
own tests would not notice a broken packer.
Repository layout
<plugin>/ one self-contained DSH plugin package
src/ source
lib/ committed build output (see below)
cordis.patch.yml the bundle patch that installs it
test/ hermetic tests, plus a non-hermetic live probe
README.md what it does, how to configure it, its permissions and risks
docs/superpowers/ design, plan, and implementation notes
Why lib/ is committed. A DSH plugin may not run a prepare or postinstall
script, so nothing may build it at install time. The build output therefore ships
in the repository, unminified. CI fails if it drifts from src/.
Development
cd <plugin>
npm run build # esbuild
npm run typecheck # tsc --noEmit
npm test # node:test — hermetic
npm run install:profile
npm run build && npm run typecheck && npm test is the same gate CI runs.
Release status
Both plugins pass the DSH-Store fixed-source precheck. Submission issues:
| Plugin | Issue | Precheck |
|---|
dsh-suggest-next-prompt | #778 | passed, 1 warning |
dsh-run-in-terminal | #779 | passed, 2 warnings, partial scan |
The precheck is a bounded static read of the pinned commit. It is not a
security audit, not a runtime verification, and not an automatic listing — the
Catalog gate that follows re-pins the source and applies stricter licence,
dependency, lifecycle, bundle and runtime-source checks before anything appears
in the store.
Two known constraints, stated rather than hidden:
scripts/install-profile.mjs in each plugin invokes npm, npm pack and
the dsh CLI through child_process so that a rebuild-and-reinstall is one
command. Both plugins' prechecks flag it. It is a local development helper: it
is not in the files list, so it is never part of a published package, and no
runtime code path reaches it. Arguments are fixed strings, not user input.dsh-run-in-terminal's committed browser bundle exceeds the scanner's
256 KiB per-file limit, because it inlines xterm. The store reports the scan
surface as incomplete for that reason. The bundle cannot simply be shrunk —
inlining is deliberate, since the shell does not seed xterm in its module
table, and a plugin may not build at install time.
License
MIT. See LICENSE.
dsh-run-in-terminal
A DeepSeek Harness web plugin that puts a Run button on every code
block in the chat and gives you a real terminal to run it in.
A fenced block in a reply grows a Run button next to the Copy button DSH
already draws. Clicking it opens an integrated terminal in the right sidebar,
pastes the snippet into it, and presses Enter. Right-click inside the terminal
for Attach selection as context (plus Copy / Paste / Select all): the
selected output is appended to the conversation draft as a fenced block, ready
to send.
Install
cd <this directory>
npm install
npm run install:profile # builds, packs, and installs into the web profile
Then restart the DSH server for that profile (dsh web) and reload the
page. A restart is required, not optional: the profile's bundle stack and the
browser's client-module graph are both composed at boot, so a new plugin cannot
appear in a running server.
npm run install:profile is the whole update loop — run it again after any
source change and restart. It takes a profile name as its first argument
(node scripts/install-profile.mjs myprofile, default web).
Why a tarball and not a local link
dsh plugin --profile web add <directory> is the usual way to install an
out-of-tree plugin, and on this machine it does not work for a plugin that
lives on a different drive than the profile: pnpm creates the node_modules
junction with the wrong target (<profile>\\D:\\projects\\dshpluginsdev,
which resolves to nothing). The launcher then cannot read the package manifest,
never sees dsh.bundle.patch, and reports
declares no dsh.bundle — installed as a plain dependency, not a profile layer.
scripts/install-profile.mjs works around it by installing from an npm
tarball, which pnpm materialises as a real directory; the bundle then
reconciles correctly (verified: dsh-run-in-terminal is appended to
dsh.profile.bundles).
What each half does
| File | Role |
|---|
src/index.ts | Host half: one persistent pty per session, served over GET /runterm/pty (WebSocket), behind a browser-trust fence. |
src/client/index.tsx | Registers the runterminal right-Sidebar page type and the code-block button pass. |
src/client/code-run.ts | Watches the transcript for .md-code-block nodes and attaches the Run button. |
src/client/terminal-view.tsx | The xterm pane, its socket, and the right-click menu. |
src/client/draft.ts | Appends a terminal selection to the composer draft through the conversation service. |
scripts/build.mjs | esbuild: the node bundle, and the browser bundle wrapped in the window.__ModuleLoader__.load boilerplate. |
How the Run button reaches the shell
openTab('runterminal', { params: { run } }) acts on the session whose
conversation is on screen and deduplicates by kind, so the click either creates
the terminal or re-navigates the one already open. The tab body watches
navigation.revision, writes the snippet to the pty as {t:'run', code}, and
the host turns a snippet into shell input:
- line endings become CR (a terminal sends Enter as CR) with one final CR to
submit, so a backslash-continued command — the shape long commands take in
chat code blocks — runs exactly as written;
- trailing blank lines are dropped, so a snippet that already ends in a newline
does not submit an extra empty command.
Framing lives on the host deliberately: the bytes the shell reads have one
authority, and that is the part covered by npm test.
The code text itself is read back as textContent of the block's content
node. DSH draws line numbers with a CSS counter, never as DOM text, so this is
the exact snippet and not a numbered copy of it.
Security
The route spawns processes, so every request passes a browser-trust fence
before it can reach one — the same fence the shipped /api gateway applies to
its own routes:
- the
Host header must name a loopback authority (a name that merely
resolves here from elsewhere is a DNS-rebinding attempt);
- a request a browser marks
Sec-Fetch-Site: cross-site is refused;
- an
Origin, when present, must name the same hostname.
This is a DNS-rebinding / cross-site defense, not authentication. It does
not distinguish one loopback page from another: a page served from the same
hostname on a different port shares the hostname and passes. If you bind DSH to
a non-loopback address, this route is exposed with everything else.
The pty starts in the session's workspace root when the client knows it, and in
the server's own working directory otherwise; a requested directory that is not
an existing directory is ignored.
Configuration
Add config.shell to the plugin row to choose the shell:
- id: run-in-terminal
name: 'dsh-run-in-terminal'
config:
shell: 'C:\\Program Files\\PowerShell\\7\\pwsh.exe'
The default is pwsh.exe on Windows when it is on PATH (powershell.exe
otherwise), and $SHELL — else /bin/bash — on POSIX, started as a login
shell.
Known limitations
- One terminal per conversation session, keyed by session id. Closing the tab
ends the process; hiding or switching away from it does not.
- A multi-line snippet is submitted line by line, so a shell control block
(
for … do … done, if … { }) run from a chat code block needs its
continuation characters — the same as pasting into a terminal that lacks
bracketed-paste support.
- The pane lives in DSH's native right Sidebar under its own kind
(
runterminal). It does not reuse and does not collide with the terminal
kind that other sidebar plugins register.
- Strings are English-only; the plugin registers no locale namespace.
Development
npm run build # esbuild: lib/index.js + the wrapped lib/client.js
npm run typecheck # tsc --noEmit
npm test # node --test test/host.test.mjs (hermetic)
npm run install:profile
The hermetic suite covers the byte framing, the transcript bound, shell
resolution, and the trust fence.
test/live-probe.mjs is the non-hermetic companion: point it at a running
server that has this plugin loaded and it asserts a same-origin handshake is
accepted, a Run frame round-trips through a real shell, and a foreign Origin
is refused.
node test/live-probe.mjs http://127.0.0.1:3080 probe
Browser bundle details: react and @deepseek-ai/* stay external (the shell
seeds them in its frozen module table), while xterm and its fit addon are
inlined, so the bundle needs no dsh.client.external entry.
