dsh-run-button
DSH 回复中的 shell 代码块运行按钮：通过主机 shell 服务执行代码片段，并将输出流式传输到右下角停靠区，或按每次运行显示在底部面板标签页中。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:EdwardXiao-bit/dsh-run-button#8c637301116e0f0a61fcc46dedbc1e1bb0b81f6dRun Button 以 dsh-run-button 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A Run button for every shell code block in a DSH reply. Press it and the snippet executes on the host, with stdout/stderr streaming live into a floating dock at the bottom-right corner (the default). No optional plugins are required: a Panel mode can instead route each run into a bottom-workbench tab, and it is the only mode that uses dsh-better-sidebar — see Output surfaces.
Status:
0.1.0— working plugin package, hand-authored (no bundler, no TypeScript build).Verified in a live DSH (
0.1.5-rc.2): the Run chip executes a command in the session's workspace, streams its output, and stops a running process. Both output surfaces were exercised end-to-end —Dockcards in the bottom-right stack, and one bottom-workbench tab per run withdsh-better-sidebarmounted.
English · 中文
DSH renders assistant answers as Markdown, and a fenced code block gets exactly one affordance: Copy. Every time an answer contains a command you want to try — a git sequence, a pnpm script, a diagnostic one-liner — you copy it, switch to a terminal, paste, and run.
This plugin adds the missing verb. Code blocks whose language is a command line get a ▶ Run chip next to Copy. Click it and:
▶ Run → ■ Stop → ✓ Run (exit 0) or ✕ Run (non-zero / killed);× to drop the run;Three modes, switchable from the strip (Dock / Panel / Off); the choice is remembered:
| Mode | Where output goes | Needs anything extra? |
|---|---|---|
| Dock (default) | One floating card per run, in a fixed bottom-right stack | no |
| Panel | A bottom-workbench tab per run — the same panel the terminal lives in | dsh-better-sidebar |
| Off | Nowhere; the chip still reports status | no |
Panel is offered through dsh-better-sidebar's public ctx.betterSidebar service (registerTab + openTab({ target: 'bottom' })), the same extension point its built-in terminal, git, and task tabs use. That plugin is an optional peer: when it is absent, Panel is disabled and Dock remains the default, so the plugin is fully usable with no extra dependency.
Cards are deliberately not anchored to the code block that started the run. Anchoring looks tidier until the block scrolls out of the virtualized transcript, the anchor lookup fails, and the same run renders in two places at once. A stable corner dock has no such failure mode.
A fence is treated as runnable when its info string names a command-line language:
| Language tag | Chip |
|---|---|
bash, sh, zsh, shell, shellscript | ▶ Run |
console | ▶ console |
powershell, pwsh, ps1 | ▶ PowerShell |
cmd, bat, batch, dos | ▶ cmd |
Other fences (js, python, json, …) are left untouched: running them would require synthesising an interpreter invocation, which is a different feature.
This is a user-initiated execution surface, and it is deliberately not more powerful than the Agent already is.
ctx.sandboxPolicy.resolve) and its workspace cwd. Pressing Run can never reach further than the Agent working in that session could.401.# junction the package into the profile's node_modules, then mount it
dsh dev inject <path-to>/dsh-run-button
The super-injector's dev_inject_plugin takes the package directory. For a durable install, add it to the profile instead:
{
"dependencies": { "dsh-run-button": "link:/absolute/path/to/dsh-run-button" },
"dsh": { "profile": { "bundles": ["...", "dsh-run-button"] } }
}
Then restart DSH (or reload the page for the client half).
npm install dsh-run-button
bash/powershell block.Panel instead gives each run its own bottom-workbench tab, with Stop, Copy, and Close.Two halves, one Cordis plugin package:
dsh-run-button/
├── package.json dsh.bundle.patch + dsh.client {platform:"web"}
├── cordis.patch.yml profile row: - insert: [{id: run-button, name: dsh-run-button}]
├── lib/index.js HOST — ESM Cordis plugin
├── lib/client.js CLIENT — classic-script bundle (window.__ModuleLoader__)
├── scripts/check-client.mjs parse gate + undeclared-global audit
└── scripts/simulate-client.mjs mounts against a real DOM and drives the whole path
Host half (lib/index.js) mounts a dedicated loopback RPC channel, /dsh-run-button, with endpoints info, start, output, input, kill. start resolves the session's cwd and sandbox policy, then uses the shipped shell service (ctx.shell.resolve → ctx.shell.start) to launch the command and hold a background process handle. output reads incremental deltas (readOutput() never repeats text) and returns a JSON-safe view: status, exit code, signal, cwd, sandbox mode, and the accumulated streams. Every side effect is a ctx.effect, including killing live processes on teardown.
Client half (lib/client.js) does three things:
MutationObserver scans the transcript for [data-code-block-banner], reads the language and the <pre> text, and appends a Run chip plus a cwd chip into the banner's action row as trailing children — React's reconciler never enumerates DOM children, so an extra trailing node survives re-renders. Because the transcript virtualizes above 100 records, re-scans run on mutation and on scroll.output every 180 ms over connection.rpc.call and notifies its subscribers; the React views render from that store, so the chip, the composer strip, and the workbench tab always agree.ctx.betterSidebar.registerTab(...) and is raised with openTab({ target: 'bottom' }) when a run starts. Its body is an ordinary React component receiving the standard TabComponentProps.The compact run strip registers in the session Slot conversation.input.dock.
Both halves are hand-written plain JavaScript:
lib/index.js is ordinary ESM — the Cordis loader imports it directly (tsconfig/tsdown not required).lib/client.js is a classic script (not a module) in the one registration format the browser kernel accepts:window.__ModuleLoader__.load({
id: "dsh-run-button", // must equal the package.json name
factory: (require) => { var module = {exports:{}}; var exports = module.exports; /* … */ return module.exports }
})
require resolves only against the shell's frozen baseline (react, react/jsx-runtime, react-dom, @deepseek-ai/cordis, …), which is why this plugin needs nothing beyond react.
Run both gates before publishing:
node scripts/check-client.mjs # parse + materialize the factory; audits for undeclared globals
node scripts/simulate-client.mjs # mount it against a real DOM and drive the whole path
simulate-client.mjs is the important one. It evaluates the bundle the way the shell does (window.__ModuleLoader__, then a Cordis-like ctx), mounts it over a happy-dom document, renders the real code-block markup, and then:
run/start and output were actually called on the RPC channel;runId — the per-run pairing, which is the thing most likely to silently regress;It exists because the earlier check-client.mjs only proved the bundle parsed. It did not run apply(), so an undeclared global (styles) sailed through and turned the whole page into "Failed to load plugins". Both bugs that shipped were caught by this harness while it was being written — which is the argument for keeping it.
lib/client.js is hand-written plain JS with no type checking behind it: an invented API or a missing required field does not fail the build — it becomes a white screen or a crashed sidebar tab. These contracts are taken from the host's own definitions.
The dynamic Cordis plugin sandbox hands out styles and harness as builtins. A shipped package bundle gets neither — referencing one throws inside apply(), and a throwing apply() takes the whole composition down ("Failed to load plugins"), not just this plugin. Every browser global is therefore reached as window.<name>, and check-client.mjs fails the build if a bare one reappears.
apply() is also wrapped in try/catch: on failure it reports, undoes whatever did mount, and returns, so this plugin can never be the reason the page stops rendering.
styles serviceThe client kernel does not provide a styles service, and ctx.get("styles") yields nothing. Insert a <style> element yourself and remove it symmetrically in teardown (apply() can run more than once):
var tag = document.createElement("style");
tag.id = PREFIX + "-styles";
tag.textContent = CSS; // in this repo CSS is a string (array .join("")), not an array
document.head.appendChild(tag);
ctx.betterSidebar.registerTab(): component is requiredTabDescriptor (see dsh-better-sidebar/src/client/service.ts):
| Field | Required | Notes |
|---|---|---|
id | ✅ | Unique id; also the SidebarTab.type. |
title | ✅ | string | (() => string) |
component | ✅ | (props: TabComponentProps) => ReactNode. Omitting it means createElement(undefined) → React #130. |
description | One line in the host's new-tab list. | |
icon | ReactNode | ((size: number) => ReactNode) | |
order | Menu sort order, default 100. | |
hidden | Keep it out of the + menu. | |
available | (ctx, scope, state) => boolean | |
single / dedupeKey | Single instance / custom dedupe. | |
createTab | Mint the tab and any state patch. | |
urlTarget | Claim external-link clicks. | |
settings / badge | Settings toggles / tab-strip badge. | |
onOpen / onActivate / onClose | Lifecycle callbacks. |
component receives TabComponentProps: ctx, store, scope, tab, and visible (active and panel open — pause polling when false).
Function declarations hoist, so component: RunTab may precede function RunTab().
dsh-better-sidebar's RenderBoundary has two scopes: ROOT (the whole sidebar shell, index.tsx) and PER-TAB (one tab, Sidebar.tsx's TabContent). Either way the strip reads dsh-better-sidebar: <message>. That prefix points at a tab registered by run-button, not at the sidebar itself — the shell and the other tabs usually stay alive.
None required. Behaviour that can be tuned:
| Knob | Where | Default |
|---|---|---|
| Poll interval | POLL_MS in lib/client.js | 180 ms |
| Simultaneous runs | MAX_LIVE_RUNS in lib/index.js | 16 |
| Per-stream output cap | MAX_STREAM_BYTES in lib/index.js | 256 KB |
| Finished-run retention | RUN_TTL_MS in lib/index.js | 10 min |
| Recognised languages | SHELL_LANGUAGES in lib/client.js | see table above |
js, python, and friends are out of scope by design).sessionStorage), but the host forgets it after that TTL or a DSH restart.input (stdin) is implemented on the host but not yet surfaced in the UI.MIT — see LICENSE.
dsh-smooth-stream also attaches to the code-block banner — for animated streaming and scroll control, not for executing the snippet. This plugin does not overlap with it: Smooth Stream changes how output is revealed, Run Button adds a control the transcript never had. The two coexist (both verified together in the same profile).