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 --version must 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):

1. Complexity — any shell metacharacter (| & ; < > \ $`) disqualifies the command. Wrapping those would silently alter what runs, so they pass through untouched.
2. Whitelist — only known dev tools that rtk actually implements are eligible (map in wrap.ts).
3. Availability — if the rtk binary is absent on PATH, 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 rtk on 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: rtk on PATH (rtk --version exits 0). The plugin does not install or manage rtk — you must install and update rtk yourself (e.g. cargo install rtk or download a release binary). When rtk is absent the plugin is a silent no-op passthrough.

Install & enable

The plugin is disabled by default — installing it does nothing until you opt in.

# 1) from a local checkout
dsh plugin --profile web add "<path-to-this-dir>"

# 2) or directly from the latest GitHub release tarball (no local clone needed)
dsh plugin --profile web add \
  "https://github.com/DeepTrial/dsh-bash-rtk/releases/latest/download/dsh-bash-rtk.tar.gz"

# enable it via an optional overlay — add to your profile's cordis.patch.yml:
#   - id: bash-sandbox
#     disabled: true
#   - id: bash-rtk
#     disabled: false

dsh 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

# 1. clone the plugin and its sibling harness
git clone https://github.com/DeepTrial/dsh-bash-rtk.git
git clone https://github.com/deepseek-ai/deepseek-harness.git

# 2. install harness deps and build the libraries the plugin links against
cd deepseek-harness && pnpm install && pnpm build:lib:host

# 3. install plugin deps and run checks
cd ../dsh-bash-rtk && pnpm install --ignore-scripts
pnpm run check        # typecheck + test + build
pnpm run test         # tests only
pnpm 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