English · 中文
--- ## Why 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: - the command runs **on the host**, in the session's own workspace directory and sandbox; - output streams into a **floating dock at the bottom-right corner** — one card per run, newest first, never covering the conversation; - the chip reflects state — `▶ Run` → `■ Stop` → `✓ Run` (exit 0) or `✕ Run` (non-zero / killed); - a run strip above the composer lists active and recent runs: click a chip to re-open that run's card, or its `×` to drop the run; - long-running commands can be stopped from the chip, the dock card, or the workbench tab. ### Output surfaces 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`](https://github.com/omdsh-dev/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. ## What it recognises 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. ## Security posture This is a **user-initiated** execution surface, and it is deliberately not more powerful than the Agent already is. - A run inherits the calling **session's sandbox policy** (`ctx.sandboxPolicy.resolve`) and its **workspace cwd**. Pressing Run can never reach further than the Agent working in that session could. - The command executes **exactly as authored** in the block. Nothing is interpolated, no shell string is assembled from model output. - The RPC channel is loopback-only and sits behind the Connection's own trust fence plus browser authentication. A credential-less request gets `401`. - Commands are executed asynchronously, so the UI never blocks; running processes are killed when the plugin stops or is updated, so no orphan survives a reload. - Output is capped at 256 KB per stream; a blocked or unauthorized command surfaces the executor's own denial in the panel. ## Install ### Into a local profile (development) ```bash # junction the package into the profile's node_modules, then mount it dsh dev inject` 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.
2. A run store polls `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.
3. The **Run output** tab registers through `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`.
### No build step
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:
```js
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:
```bash
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](https://github.com/capricorn86/happy-dom) document, renders the real code-block markup, and then:
- asserts the Run chip was injected into the banner and clicks it;
- asserts `run/start` and `output` were actually called on the RPC channel;
- switches output mode and asserts dock cards appear, then disappear, and that exactly one dock container exists with one card per run;
- asserts the tab type is registered, does **not** dedupe, and that two runs produce **two distinct tab ids each carrying its own `runId`** — the per-run pairing, which is the thing most likely to silently regress;
- unmounts and asserts nothing was left behind.
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.
## Host contracts (read before touching the client half)
`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.
### There are no ambient globals
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.`, 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.
### Injecting CSS: there is no `styles` service
The client kernel does **not** provide a `styles` service, and `ctx.get("styles")` yields nothing. Insert a `