dsh-bash-rtkDeepSeek Harness plugin
DeepSeek Harness bash executor plugin that routes eligible commands through rtk (Rust Token Killer) to compress tool output and save tokens.
- Stars
- 10
- Forks
- 1
- License
- MIT
- Last commit
- Aug 25, 2026
- Latest release
- v0.1.1
Overview
DeepSeek Harness bash executor plugin that routes eligible commands through rtk (Rust Token Killer) to compress tool output and save tokens.
Original README
Cached from the project repository on Sep 3, 2026. This is source content, separate from the Agents.md review above.
dsh-bash-rtk
Route eligible shell commands through rtk (Rust Token Killer) inside the DeepSeek Harness (
dsh) bash executor — compress tool output, save tokens, change nothing else.
Table of Contents
- Quick Example
- Requirements
- Why
- How it works
- Install & enable
- API / Configuration
- Which commands are routed
- Development
- License
Quick Example
The plugin rewrites commands at the resolve() boundary — before anything runs:
Input (command) | Resolved output | Reason |
|---|---|---|
git status | rtk git status | Simple + whitelisted |
cargo build --release | rtk cargo build --release | Simple + whitelisted |
git status | grep x | git status | grep x | Complex shell — passthrough |
ls -la | ls -la | Not whitelisted — passthrough |
git status (rtk absent) | git status | Binary missing — identity fallback |
Everything else — workdir, timeout, env, exit code, sandbox confinement — is inherited unchanged.
Requirements
- Node.js: >= 20.0.0
- rtk:
rtk --versionmust exit 0 on PATH (install separately, e.g.cargo install rtk)
Why
LLM agents burn tokens on verbose tool output (git log, cargo build, pytest trails…). rtk already knows how to shrink those for 30–90%. This plugin bolts that filtering onto dsh's bash executor so every eligible command is auto-routed through rtk — with zero semantic change to what actually runs.
How it works
model → dsh bash tool → RtkBashExecutor.resolve()
│
┌───────────────┴────────────────┐
eligible? not eligible
(simple + whitelisted) (complex / unknown)
│ │
rtk <subcommand> … command runs unchanged
(rtk compresses output) (byte-for-byte passthrough)
Three independent guards decide (see src/wrap.ts):
- Complexity — any shell metacharacter (
| & ; < > \$`) disqualifies the command. Wrapping those would silently alter what runs, so they pass through untouched. - Whitelist — only known dev tools that
rtkactually implements are eligible (map inwrap.ts). - Availability — if the
rtkbinary is absent onPATH, the transform is the identity: the deployment behaves exactly like the stock local executor.
Versioning note
The plugin does not bundle or pin rtk. At dsh startup it probes rtk --version on PATH (see resolveRtk() in src/index.ts). Therefore:
- When rtk ships a new release, any user who upgrades
rtkon their machine automatically gets the new behavior — no plugin update required. - The plugin version (this repo) and the rtk version are independent; keep them separate. This README states the minimum rtk version tested against, not a lockstep number.
Requires:
rtkonPATH(rtk --versionexits 0). The plugin does not install or manage rtk — you must install and update rtk yourself (e.g.cargo install rtkor download a release binary). When rtk is absent the plugin is a silent no-op passthrough.
Compatibility & version alignment
This plugin depends on three @deepseek-ai/dsh-* packages that DeepSeek Harness publishes to npm independently from the dsh aggregate package. Because those sub-packages (and dsh itself) ship as prereleases (x.y.z-rc.n), the peer ranges must carry an explicit prerelease branch per awesome-dsh-plugin/contributing.md — a broad-looking range like >=0.0.1-rc.1 <0.2.0 would silently exclude every 0.1.0-* / 0.1.1-* prerelease (node-semver only lets a prerelease satisfy a range if some comparator shares its exact major.minor.patch tuple and also carries a prerelease tag).
The actual ranges (see peerDependencies in package.json) are:
"@deepseek-ai/dsh-bash-local": ">=0.0.1-rc.1 <0.1.0 || >=0.1.0-rc.1 <0.1.1 || >=0.1.1-rc.1 <0.2.0-0"
"@deepseek-ai/dsh-bash-sandbox": ">=0.0.1-rc.1 <0.1.0 || >=0.1.0-rc.1 <0.1.1 || >=0.1.1-rc.1 <0.2.0-0"
"@deepseek-ai/dsh-shell": ">=0.0.1-rc.1 <0.1.0 || >=0.1.0-rc.1 <0.1.1 || >=0.1.1-rc.1 <0.2.0-0"
cordis is not a peer dependency: it is injected by dsh at runtime, so declaring it would break install for anyone on a registry that lacks a matching published cordis. All three @deepseek-ai/dsh-* peers are marked optional in peerDependenciesMeta, so the plugin still loads where they are absent (it then behaves as a passthrough).
The plugin's dsh.plugin.json declares:
json"engines": { "dsh": ">=0.1.0-rc.6 <0.2.0 || >=0.1.1-rc.1 <0.2.0-0" }
i.e. it is verified against dsh 0.1.1-rc.2, accepts any 0.1.x prerelease/build, and deliberately excludes 0.2.0+ (a future major that may change the LocalBashExecutor.resolve() / ShellExecSpec API — a sub-package bump will be required before this plugin can track it).
Known version skew:
dsh(the aggregate, whatnpx @deepseek-ai/dshinstalls) and its@deepseek-ai/dsh-*sub-packages are on separate semver tracks — the aggregate can be0.1.1-rc.2while the published sub-packages are still0.0.1-rc.1. The ranges above pin to the published sub-package versions so a plaindsh plugin addresolves cleanly. Watch the releases for a matching update.
Install & enable
The plugin is disabled by default — installing it does nothing until you opt in.
sh1# 1) from a local checkout 2dsh plugin --profile web add "<path-to-this-dir>" 3 4# 2) or directly from the latest GitHub release tarball (no local clone needed) 5dsh plugin --profile web add \ 6 "https://github.com/DeepTrial/dsh-bash-rtk/releases/latest/download/dsh-bash-rtk-latest.tgz" 7 8# enable it via an optional overlay — add to your profile's cordis.patch.yml: 9# - id: bash-sandbox 10# disabled: true 11# - id: bash-rtk 12# disabled: false 13 14dsh web # restart to apply
The bundled overlay snippet lives in cordis.patch.yml. It swaps the stock sandbox executor for RtkSandboxBashExecutor (file confinement preserved) and leaves the unconfined RtkBashExecutor available for danger-full-access setups.
API / Configuration
Both executors accept the same base config as their stock counterparts (LocalBashExecutor / SandboxBashExecutor) plus one optional field:
| Option | Type | Default | Description |
|---|---|---|---|
rtkAvailable | boolean | resolveRtk() result | Force-enable or force-disable rtk wrapping. Useful for tests or deployments where the binary path is non-standard. |
All other options — cwd, timeoutMs, graceMs, etc. — are inherited unchanged from the upstream executors.
Which commands are routed
The set of commands eligible for rtk-wrapping is defined by rtk itself — see the rtk command reference / README.md for the authoritative, maintained list. This plugin mirrors that list; when rtk adds a new subcommand, upgrade rtk (not this plugin) to pick it up.
Complex commands — pipelines, &&/;, redirects, $( ), env assignments — always run natively regardless of the whitelist.
Development
sh1# 1. clone the plugin and its sibling harness 2git clone https://github.com/DeepTrial/dsh-bash-rtk.git 3git clone https://github.com/deepseek-ai/deepseek-harness.git 4 5# 2. install harness deps and build the libraries the plugin links against 6cd deepseek-harness && pnpm install && pnpm build:lib:host 7 8# 3. install plugin deps and run checks 9cd ../dsh-bash-rtk && pnpm install --ignore-scripts 10pnpm run check # typecheck + test + build 11pnpm run test # tests only 12pnpm run typecheck # tsc only
devDependencies use link: into the local deepseek-harness checkout; tests run inside that workspace (the @deepseek-ai/dsh-* packages must resolve).
License
MIT