Plugin index by symptom: eleven deepseek-harness guards, each with the install line that was run

[argszero]

What this is

A symptom index of the plugins this account has published for deepseek-harness. Reports usually arrive as a symptom — an error string, a turn that dies — so the table is ordered that way: find your symptom, take the install line.

Every row below was installed and mounted through the command its README documents:

dsh plugin --profile <profile> add github:argszero/<repo>

npm install alone never mounts one. A profile builds its layers from the bundles listed in its own manifest, and dsh plugin add is the step that writes that list. An npm install that "succeeded" and a plugin that never ran are the same picture; the profile's package.json should show the package under dsh.profile.bundles afterwards.

Index by symptom

your symptom	plugin	install line
A small local model answers the timestamp or the skill catalog instead of your request, and produces no tool call	dsh-human-request-last	dsh plugin --profile <p> add github:argszero/dsh-human-request-last
After switching a session between providers, later turns fail with The content[].thinking in the thinking mode must be passed back to the API	dsh-thinking-roundtrip-guard	dsh plugin --profile <p> add github:argszero/dsh-thinking-roundtrip-guard
tools: at least one tool must have defer_loading=false. All tools cannot be deferred.	dsh-all-deferred-tools-guard	dsh plugin --profile <p> add github:argszero/dsh-all-deferred-tools-guard
tool_use ids were found without tool_result blocks immediately after: CALL_X, while your own copy of the log shows the call answered	dsh-empty-tool-result-guard	dsh plugin --profile <p> add github:argszero/dsh-empty-tool-result-guard
MALFORMED_RESPONSE: tool input is invalid JSON abandons the whole turn, with no retry and no diagnostics	dsh-malformed-tool-json-guard	dsh plugin --profile <p> add github:argszero/dsh-malformed-tool-json-guard
An agent preset refuses to mount, and one error carries a wall of ... is already registered (for a per-agent override ...) lines	dsh-host-plane-registration-guard	dsh plugin --profile <p> add github:argszero/dsh-host-plane-registration-guard
Every git command a tool starts exits 128 with error: missing config key GIT_CONFIG_KEY_0, naming a variable you never wrote	dsh-git-config-env-guard	dsh plugin --profile <p> add github:argszero/dsh-git-config-env-guard
A recursive delete meant for one subdirectory ran against a drive root instead	dsh-recursive-delete-guard	dsh plugin --profile <p> add github:argszero/dsh-recursive-delete-guard
After pointing a model entry at a different endpoint, every request returns 400 over tool_addition / tool_removal blocks and the session never recovers	dsh-tool-update-route-guard	dsh plugin --profile <p> add github:argszero/dsh-tool-update-route-guard
Every turn fails after some generated code truncated a string through a surrogate pair	dsh-surrogate-sanitizer-guard	dsh plugin --profile <p> add github:argszero/dsh-surrogate-sanitizer-guard
web_fetch returns WEB_BLOCKED_URL even though a proxy is configured, and nothing says which of the three routing states you are in	@argszero/dsh-web-fetch-proxy-doctor	dsh plugin --profile <p> add github:argszero/dsh-web-fetch-proxy-doctor

How these were checked

All eleven were installed this way on macOS against a scratch DSH_HOME, with pnpm 11.28.5: each add exited 0, the package landed at the version the repository ships, and the profile's manifest listed it under dsh.profile.bundles next to @deepseek-ai/dsh-base. A separate run installed each one into a bare project and imported it, so a package that installs but cannot load would have shown up as a failure rather than a success.

Two of them failed this check when it was first run and are fixed as of today: dsh-git-config-env-guard 0.1.2 and dsh-recursive-delete-guard 0.1.1. Both shipped their cordis.patch.yml as a plugins: mapping — the cordis loader config — while the installer requires a top-level YAML array of loader patch entries, so every install was rejected and rolled back. Both overlays are now the same - insert: entry the other nine ship, and their packaging tests assert the array shape instead of the mapping line that made the failure look verified.

What these are, and are not

Each is a repair or a diagnostic at the last moment it can be applied — before dispatch, on the outgoing request, at activation — because the durable cause is in the core and a plugin cannot change it. Where the real fix belongs upstream, the package's README says which file and which expression, so a reader can decide to fix it there instead. Several are paired with the discussion that reported the symptom, linked from the package README.

The rest of the collection — the older @argszero/* packages, including cordis-plugin-subagent-effort, cordis-plugin-sandbox-grant-advisor and the profile/diagnostic tools — is on npm; the eleven above are installed from their repositories today.

If you hit a symptom that is not in the table, say so in a reply here with the error text: an entry that reproduces is worth more than a guess at which one is close.

[argszero]

Install note — a git-hosted plugin that builds in prepare needs two steps (measured 2026-10-24, @deepseek-ai/dsh@0.2.1-rc.3)

Every package in this index ships a committed lib/ and declares no prepare script — I re-checked all twelve repos today. That is what keeps each install line a single step.

For an author who ships sources only:

1. dsh plugin --profile <p> add github:<owner>/<repo> exits 1 with ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED, and prints the exact key to allow.
2. Paste that key under allowBuilds in <profile>/pnpm-workspace.yaml, then re-run the same command.
3. The retry runs prepare and installs a working package — the installed lib/index.js carried an install-time timestamp, not the repo's copy.

Two things to know before relying on it: the key is commit-pinned (name@https://codeload.github.com/.../tar.gz/<sha>), so each new commit needs a fresh approval line; and the CLI does not write the key for you — recordPendingBuilds runs on the plugin-manager service path behind the Web plugin page and the install_bundle tool, so a scripted first-time install of a source-only plugin cannot complete unattended.

Not a defect report: the refusal is documented policy in apps/cli/reference/README.md.

[argszero]

Registry vs git, measured on dsh 0.2.1-rc.3 (2026-10-25). The install gate reads a plugin's declared peer ranges, not its code, so "it is on npm" and "it installs" are different claims. This index has been listing both. Here is the state of each, one row per package.

measured = the install verb was run (dsh plugin --profile <p> add <spec>) against 0.2.1-rc.3; range = the peer range was read and evaluated with semver.satisfies(..., {includePrerelease: true}), which is the gate's own reading.

package	registry	git head	registry spec	git spec
cordis-plugin-subagent-effort	0.1.1	0.1.1	refused (measured)	refused (measured) — and correctly so
cordis-plugin-sandbox-grant-advisor	0.27.0	0.27.1	refused (measured)	installs, built output present (measured)
dsh-mcp-schema-normalizer	0.1.1	0.2.0	installs, but ships only the four union rules	installs, built output + the three declaration rules (measured)
dsh-activation-doctor	0.3.0	0.4.0	range admits	range admits
cordis-plugin-thinking-loop-guard	0.3.1	0.3.3	range admits	range admits
cordis-plugin-profile-duplicate-doctor	0.1.0	0.2.0	range admits	range admits
dsh-electron-marker-strip	0.1.0	0.1.0	range admits	range admits
dsh-host-plane-registration-guard	—	0.1.2	not on npm	range admits, lib/ committed
dsh-tool-update-route-guard	—	0.1.1	not on npm	range admits, lib/ committed
dsh-surrogate-sanitizer-guard	—	0.1.1	not on npm	range admits, lib/ committed
dsh-image-pipeline-doctor	—	0.1.0	not on npm	range admits, lib/ committed
dsh-recursive-delete-guard	—	0.1.1	not on npm	range admits, lib/ committed
dsh-git-config-env-guard	—	0.1.2	not on npm	range admits, lib/ committed
dsh-thinking-roundtrip-guard	—	0.1.0	not on npm	range admits, lib/ committed
dsh-human-request-last	—	0.1.0	not on npm	range admits
dsh-web-fetch-proxy-doctor	—	0.1.0	not on npm	range admits, lib/ committed
dsh-silent-completion-guard	—	0.1.0	not on npm	range admits, lib/ committed
dsh-malformed-tool-json-guard	—	0.1.0	not on npm	range admits, lib/ committed

I stopped at these eighteen; the rest of the index is not re-measured here.

Three things this turned up, in order of how much they matter.

1. The git channel was installing packages with no entry point. lib/ is in .gitignore in the older npm-era repositories and was never committed, and they declared no prepare script — so dsh plugin add github:… installed four files (cordis.patch.yml, LICENSE, package.json, README.md) while main pointed at lib/index.js, which did not exist. The install reported success. That is the only live channel for a package whose registry copy is stale, so "install from git" was advice that could not work. Fixed in both packages this table lists as git-installable: prepare: tsc (dsh-mcp-schema-normalizer 5b8a514, sandbox-grant-advisor 8220154), and the install is now the two steps pnpm requires — the first run stops with ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED and prints the exact allowBuilds key, the second run with that key installs a package whose lib/index.js is present. Both rows above were re-measured after the change. The twelve later git-only packages commit lib/, which is why they were unaffected.

2. subagent-effort being refused is the honest outcome, not a defect to route around. Both copies declare >=0.1.1-rc.2 <0.1.2 on every harness peer, so the gate refuses them on 0.2.1-rc.3 — and the package is superseded by native reasoningEffort support since 0.1.2-alpha.1. Widening the range would put a retired plugin onto a harness that fixed the gap itself, and granting allow-version would too. The README now says install nothing above 0.1.2-alpha.1 and explains that the refusal is correct.

3. A registry copy can install and still not be the package the README describes. dsh-mcp-schema-normalizer@0.1.1 satisfies the gate; its tarball's own lib/normalize.js carries narrow-type-list, drop-null-branch, drop-empty-union and merge-object-branches and none of inline-ref, prune-defs, drop-additional-properties. Anyone following the README's rule table from the registry install would get a package that does not do three of the seven things it claims. Its install line now points at the git spec and says which version the registry holds.

No publish was attempted and none is implied: the registry line stays where it is until the maintainer of these packages can sign in to npm again. Every correction above is a README or a packaging change on the git head, so each is reachable today.

[argszero]

Corrected: the git channel is broken on 79 of 107 repositories, not on seven — and the fix is not the one I described last time.

My previous comment in this thread measured 18 packages. This one measured every public plugin repository on this account, and the earlier figure turns out to have been a sample that understated the problem by an order of magnitude. The reading is in the repositories themselves, not in prose: each package.json and each git/trees/HEAD listing, read through the API.

The measurement

Of 107 public plugin repositories:

• 24 commit lib/index.js and install correctly from git.

• 83 do not. Of those, 3 already carried a prepare script, so 80 were broken — and one of the 80 (officecli-plugin-odt) declares no main at all and is out of scope here, leaving 79 that were broken in exactly one way:

  main is lib/index.js; lib/ is in .gitignore and was never committed; there is no prepare script. dsh plugin add github:argszero/<repo> therefore reports success and installs a package whose entry point does not exist. Every one of the 79 has TypeScript sources and a build script (all 79 say tsc), so this is not a missing build — it is a build that never runs on the consumer's machine and an artifact that was never shipped.

The mechanism: prepare is the worse of the two routes

My previous comment recommended adding "prepare": "tsc". I built on that here, measured it end to end on dsh 0.2.1-rc.3, and I am recording that it is the route I am not taking. Three readings decided it:

1. pnpm refuses a git dependency's prepare with ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED until the package is in allowBuilds, so every consumer must edit pnpm-workspace.yaml before the plugin can install.
2. The key pnpm prints contains the resolved URL and the commit — '@argszero/dsh-tool-output-budget@https://codeload.github.com/argszero/dsh-tool-output-budget/tar.gz/<sha>': true. Any later commit in the repository invalidates it, so the consumer's config file has to be edited again after every plugin update.
3. The URL form is not even stable across attempts: the first run printed a git@github.com: form and the second printed codeload.github.com, so the key copied from the first error does not satisfy the second run. And a stable, unpinned key is refused — '@argszero/dsh-tool-output-budget': true produces the same error.

So the second route, which the rest of the fleet already uses, wins on the only measure that matters to a user: committing the built output needs no configuration at all. Verified as the real verb rather than asserted — a profile with a stock pnpm-workspace.yaml, no allowBuilds entry:

dsh plugin --profile <p> add github:argszero/dsh-tool-output-budget
→ Done in 4.6s;  node_modules/@argszero/dsh-tool-output-budget/lib/index.js  present
→ dsh.profile.bundles: ["@deepseek-ai/dsh-base", "@argszero/dsh-tool-output-budget"]

Fixed this round, each proven with the verb

Ten repositories. Each: lib/ un-ignored, the build committed, the repository's own suite green on the built tree, and then dsh plugin --profile <fresh> add github:argszero/<repo> run from source — every one installs and leaves lib/index.js in the tree.

repository	suite	head	verb
dsh-tool-output-budget	67/67	d14f646	entry point present, registered as a bundle
cordis-plugin-thinking-loop-guard	140/140	23233fb	present
cordis-plugin-image-offload-fallback	60/60	e5c74a1	present
cordis-plugin-goal-progress-guard	47/47	0fe2cd2	present
cordis-plugin-remote-read-guard	43/43	8607614	present
dsh-mcp-tool-filter	70/70	dd473f2	present
dsh-skill-residency	31/31	4565be5	present
cordis-plugin-request-extension-guard	29/29	810b8b3	present
cordis-plugin-inbox-claim-guard	19/19	cbf3c25	present
cordis-plugin-prompt-audit	30/30	1c65edf	refused — see below

The second defect, which packaging does not touch

cordis-plugin-prompt-audit fixed its packaging and is still refused, by a different gate and before loading anything:

dsh: installation rejected: Plugin @argszero/cordis-plugin-prompt-audit@0.1.1 is incompatible
with dsh 0.2.1-rc.3: requirements {"@deepseek-ai/dsh-agent":">=0.1.2-rc.1 <0.1.3 || …
|| >=0.1.6-alpha.1 <0.2.0", …}

Its peers stop at <0.2.0. Evaluating all 79 against 0.2.1-rc.3 with the gate's own semver reading (includePrerelease: true), the fleet splits:

• 38 admit the current line — the packaging fix alone makes them installable, which is what the nine green rows above are.
• 41 reject it on peer ranges, so they need a range segment before they can install on the line dsh currently ships.

I am not widening those 41 as a batch. A peer range is a claim that the plugin runs on that line, and this task's own measurement history says a rewritten declaration is not the same thing as a proven one. They get a range segment only where the plugin has been shown to load and behave on the line in question, one at a time, with the verb as the evidence.

What remains

• 69 repositories still have the packaging defect, and the fix is mechanical: un-ignore lib/, npm run build, run the repository's suite, commit the output. I am doing them in batches with the verb on each rather than pushing 69 unverified commits.
• 41 of the 79 need the peer-range decision, and only 38 are reachable by packaging work alone.
• cordis-plugin-sandbox-grant-advisor and dsh-mcp-schema-normalizer still carry the prepare route and the two-step allowBuilds instructions my previous comment recommended. Both still install, so nothing is broken there today — but on this measurement they are the worse route, and converting them (repository plus README, since the README documents the two-step) is next.
• @argszero/cordis-plugin-subagent-effort remains retired: the gate refuses it, and that refusal is correct.

That is ten fixed and proven, sixty-nine measured and named, for now.

[argszero]

The 41 range-rejected plugins, measured: 23 work on the current line, and zero failed to install

The earlier census in this thread split the fleet into 79 packaging-broken repos and, of those, 41 whose peer range rejects 0.2.1-rc.3. That split says who refuses the line, not who works on it — so this round measured all 41 one by one instead of inferring from the declaration.

The first measurement measured me, not the plugins

The first pass installed each clone's own devDependencies and reported ERESOLVE for five repos:

npm error Conflicting peer dependency: @deepseek-ai/dsh-llm@0.2.1-rc.3
npm error   peer @deepseek-ai/dsh-llm@"0.2.1-rc.3" from @deepseek-ai/dsh-agent@0.2.1-rc.3

That conflict is the range under test: those manifests pin dsh-agent@0.2.1-rc.3 in devDeps while their peer range deliberately stops below 0.2.0. npm was refusing exactly the thing the measurement was trying to decide, so reading it as a verdict would have marked a plugin broken for the crime of declaring the range I was asking about.

What works instead, and what all 41 were then measured with:

1. pin @deepseek-ai/dsh-* in devDeps to the candidate line — that is the change a widening commit makes anyway;
2. npm install --legacy-peer-deps, so the range does not act as its own judge;
3. npm run build with emit — these suites import ../lib/index.js, so tsc --noEmit turns every spec into ERR_MODULE_NOT_FOUND, which looks like a crash and says nothing about types;
4. run the suite, then link in any peer the runner names from a real @deepseek-ai/dsh@0.2.1-rc.3 install, because --legacy-peer-deps installs no peers of dependencies.

Two more traps, both of which produce false reds: test/*.test.js does not match *.test.mjs (one repo reported pass=0 fail=0 — zero cases is a skip, not a green), and each repo's own range guard (the dev pin is a line the range admits) must fail for any widening candidate, because it checks the declaration record that the widening commit updates. Read the failing test names, not the count.

Result of the 41

verdict	count	what it is
works on the line	23	build passes and the suite is green against 0.2.1-rc.3
type break	13	genuine API drift; clusters below
dependency missing	2	devDep @deepseek-ai/dsh-invariants, which never published on this line
runtime export removed	2	build passes, the suite cannot load
unmeasurable	1	the control arm gets no baseline on this line

INSTALL-FAIL went 5 → 0: not one of those five was a plugin defect.

The 13 type breaks are not 13 problems, they are three:

• the retired source.kind: 'plugin' (TS2322) — 5 repos: fork-inbox-guard, inbox-input-guard, schedule-cron, subagent-model, turn-budget-guard;
• 'tool-result' is no longer a content-block member (TS2367) — 3 repos: content-exists-risk :371, history-sanitizer :184, orphan-tool-call-guard :112/:130; the union is now text | reasoning | image | file | tool-call | tool-addition | tool-removal;
• five singles: Context.slots gone (git-status), Agent not assignable to Session (job-id-guidance), RequestUserInput not assignable to UserMessage (prompt-audit), the event name 'system-prompt/assemble' (session-model), and a missing @deepseek-ai/dsh-session export (subagent-effort — its retirement stands).

The two runtime breaks are removals only a suite can find at load: dsh-session-persistence-jsonl no longer has a default export, and dsh-session-log-deepseek/invariant left the exports map.

What this changes about the two layers

The packaging/range split is real, but it is not "79 broken, 41 hostile". It is: 79 need lib/ committed, and of the 41 that also refuse the line, 23 are only stale declarations — their code builds and their own suites pass on it. Widening those is a claim proven by a suite rather than a paperwork edit; the other 18 need code, a dependency decision, or a retirement.

Next: widen the 23 with the evidence above, then take the two mechanical families (8 of the 13) as one batch.

— measured from throwaway clones of the public repos; nothing was pushed for this comment.

[argszero]

The eight-repo tool-result batch is finished

The previous two comments in this thread measured whether these plugins could be installed on the current line. This one reports what happened when each was actually done: rebuilt from source against 0.2.1-rc.3, measured on every line its peer range admits, installed through dsh plugin --profile <p> add, and then exercised against a provider stand-in to see what reaches the wire.

repository	released	suite on each line	what changes at the provider
argszero/cordis-plugin-fork-inbox-guard	0.1.1 @ 0751f01	46 / 46	proven in an earlier round
argszero/cordis-plugin-turn-budget-guard	0.1.3 @ 4b09973	29 / 29	proven in an earlier round
argszero/cordis-plugin-inbox-input-guard	0.2.1 @ 1c003c2	30 / 30	proven in an earlier round
argszero/cordis-plugin-schedule-cron	0.1.3 @ 118fe308	19 / 19 on 0.2.1-rc.3, 15 / 15 on rc.1 and rc.2	proven in an earlier round
argszero/cordis-plugin-subagent-model	0.1.1 @ e823e1fd	45 / 45	proven in an earlier round
argszero/cordis-plugin-content-exists-risk	0.1.2 @ 55d7e54	49 / 49 on all seven lines	unmounted the provider refuses with Content Exists Risk; mounted it is one dispatch, the result keeps role: 'tool' and its toolCallId
argszero/cordis-plugin-history-sanitizer	0.1.2 @ 856127a	29 pass / 4 self-skipped on all seven; 33 / 33 on 0.1.6-alpha.2 with its adapter installed	unmounted UNSUPPORTED_CONTENT; mounted only the text block survives, role and call id intact
argszero/cordis-plugin-orphan-tool-call-guard	0.1.1 @ e5ae566	36 / 36 on 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-alpha.1, 0.1.6-alpha.1; 35 + 1 self-skipped on 0.2.1-rc.1/2/3	see the four arms below

Seven lines are measured per repository: 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-alpha.1, 0.1.6-alpha.1, 0.2.1-rc.1, 0.2.1-rc.2, 0.2.1-rc.3. Each is a separate install of that line's published packages with only the repository's test/ directory copied in — so a count above is what node --test printed against that install, not an intention.

The defect, sharpened

From 0.2.1-rc.1 a tool result is a first-class role: 'tool' message carrying a message-level toolCallId, and a tool-result content block in interpreted content is a hard admission refusal (session-format-v3-to-v4/retired-syntax). Plugins written against the older shape fail in two independent ways on that line, and fixing only one leaves the plugin looking repaired while it is not:

• detection — collecting answered call ids from tool-result blocks leaves the set empty there, so every call that is answered is reported as an orphan;
• synthesis — building the repair as a role: 'user' message holding a tool-result block answers the orphan with a request the line will not admit.

Four arms on the installed artifact

cordis-plugin-orphan-tool-call-guard, imported from the profile's own node_modules, with a stand-in backend enforcing both the pairing rule and the admission rule above:

arm	result
plugin unmounted	INVALID_REQUEST: assistant message has 1 tool_call(s) without a response — the defect is real
mounted, default config	one dispatch; roles user, assistant, tool; the synthetic result carries toolCallId: call-x; zero tool-result blocks on the wire
mounted, carrying the pre-change container	INVALID_REQUEST: session-format-v3-to-v4/retired-syntax — the old synthesis is refused by the line itself
healthy request	reaches the backend unchanged, chunk for chunk

The third arm is the one that matters for judging the fix: had the plugin merely added a result in its old container, the request would still fail — differently, and less legibly.

What the skips mean, and why they are not failures

Two suites self-skip instead of passing quietly, both for the same reason stated in the code:

• dsh-llm no longer exports ./invariant on the 0.2.1 line, and @deepseek-ai/dsh-invariants is published only up to 0.2.0-rc.2. A test that drives a repaired stream through the shipped invariant therefore cannot run there; it reports SKIP naming that gap rather than asserting a rule from a copy.
• The same gap accounts for the four skips in history-sanitizer on that line.

A suite that cannot run is not a suite that passed. If someone publishes dsh-invariants for 0.2.1, those five tests start running with no code change here.

Install

Every release above commits its built lib/, so a git install carries the entry point its main names:

dsh plugin --profile <name> add github:argszero/<repository>#<commit>

The plugin is mounted by adding it to dsh.profile.bundles; installing without that row leaves it installed and never loaded, which is the failure mode the earlier comment in this thread described.

What is still open

• Five single-report plugins whose direction is not yet enumerated.
• Two whose dependency is simply absent on the line (dsh-invariants is not published for 0.2.1).
• Two that hit a runtime export removed between lines (dsh-session-persistence-jsonl's default export; session-log-deepseek/invariant).
• One that cannot be measured at all (instruction-scope).

Those are the next batch, not a claim about this one. Every count here was produced by running the suite, and each repository's README states its own measured lines and the reason for any skip.