dsh-run-in-terminal
DSH 网页插件：每个聊天代码块都提供“运行”按钮，可将代码粘贴到集成终端；还可从终端输出中“将选中内容附加为上下文”。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:DIV7NE/dsh-plugins#1ef9db37dbad68657206500abde058dcdf69d23cRun In Terminal 以 dsh-run-in-terminal 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
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. |
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.
dsh-chrome-agent ships two artifacts from one directory, and they are released
separately:
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.
<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/.
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.
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.MIT. See LICENSE.
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.
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).
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).
| 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. |
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:
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.
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:
Host header must name a loopback authority (a name that merely
resolves here from elsewhere is a DNS-rebinding attempt);Sec-Fetch-Site: cross-site is refused;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.
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.
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.runterminal). It does not reuse and does not collide with the terminal
kind that other sidebar plugins register.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.