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 rtkactually implements are eligible (map inwrap.ts). 3. **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 dshstartup it probesrtk --versiononPATH(seeresolveRtk() in [src/index.ts](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 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. ```sh # 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](cordis.patch.yml). It swaps the stock sandbox executor for RtkSandboxBashExecutor(file confinement preserved) and leaves the unconfinedRtkBashExecutoravailable fordanger-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](https://github.com/rtk-ai/rtk#supported-ecosystems) / [README.md](https://github.com/rtk-ai/rtk/blob/develop/README.md#test-runners) 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 ```sh # 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 ``` devDependenciesuselink:into the localdeepseek-harnesscheckout; tests run inside that workspace (the@deepseek-ai/dsh-*` packages must resolve). ## License MIT