dsh-plugin-immune

Your coding agents stop re-debugging what they already fixed.

97.54% agreement replaying 20,100 real tool calls · 0 false negatives · zero runtime dependencies

measured, not asserted — how the number was produced

English | 简体中文

When a tool call fails and the next attempt fixes it, the plugin saves that pair as a rule. Rules that match the current work get injected into context on later runs, before the agent repeats the same mistake.

One core/ engine: DSH and ZCode install natively (plugin bundles, checked against the real host contracts), and immune connect wires the same engine into Claude Code and Codex CLI as plain hooks — no plugin system required.

The dashboard as any install sees it — the capture uses demo rules, not a private library.

Quick demo

Runs the whole pipeline in memory, installs nothing, writes nothing:

npx dsh-immune-system@latest demo

It distills a failure→success episode, recalls it from a paraphrased prompt, and prints the ` block the hooks inject. Already have history on this machine? npx dsh-immune-system@latest audit --dry-run` reads it and shows what would be learned.

Install

DSH — from npm (prebuilt, no toolchain):

dsh plugin --profile  add dsh-immune-system

Same package from a tarball or from git:

cd dsh-immune-system && npm pack        # prints the exact dsh-immune-system-.tgz it wrote
dsh plugin --profile  add ./dsh-immune-system-.tgz
dsh plugin --profile  add github:meat-daemon-404/dsh-plugin-immune

The github: form builds at install time through prepare, which pnpm blocks until it is allowlisted (the Chinese README has the exact setting). npm or the tarball sidesteps that.

Restart DSH afterwards; plugin bundles are composed at startup.

ZCode — this repository is itself a marketplace source:

node "" plugins marketplace add meat-daemon-404/dsh-plugin-immune
node "" plugins install dsh-immune-system@dev-dsh-plugin-immune

Start a new task afterwards; existing tasks keep the capability catalog they started with.

Hooking Claude Code & Codex

Native plugin installs are for DSH and ZCode. For Claude Code and Codex CLI the

same engine installs as plain hooks — no plugin system required:

npx dsh-immune-system@latest connect claude-code   # writes ~/.claude/settings.json
npx dsh-immune-system@latest connect codex         # writes ~/.codex/hooks.json

What it does: copies the engine into a fixed ~/.dsh-immune/ install (so the

hooks survive npx-cache cleanups and package upgrades), merges six hook

entries (five on Codex, which has no PostToolUseFailure event) into the

host's own config pointing there, leaving every other setting alone;

keeps a one-time .bak-immune backup before the first write; re-running is a

no-op (--refresh forces a re-copy); a stale install — an npx cache path from

an older connect — is upgraded in place; connect --remove takes only

the immune entries back out and deletes ~/.dsh-immune/ when no host remains.

Bare connect surveys both hosts read-only. immune doctor reports broken

hook paths with the exact reconnect command. The hook payload contract is the

one the ZCode adapter already speaks (same hookSpecificOutput injection

shape), so no adapter code ships per host.

Two notes: restart the host session after connecting, and **Codex requires

running /hooks inside Codex once to trust the commands** before they fire.

Auditing the history you already have

A fresh install has an empty library. immune audit replays the same

failed-then-fixed pairing over the session history already on this machine —

the ZCode session db, Codex rollout files (~/.codex/sessions), and Claude

Code transcripts (~/.claude/projects) — prints a shareable summary (per-tool

failure counts, top repeat offenders, the avoidable token cost when the source

records usage), and distils your own first rules from it: