disk-hygiene: destructive-operation guard silently unenforced for the entire measured window

[kyle-sexton]

Summary

disk-hygiene's destructive-operation guard has been silently unenforced for the entire measured
window. Both registered variants fail before any guard logic runs, and both fail non-blockingly —
so the tool call proceeds and nothing surfaces to the operator.

This was found incidentally while diagnosing guardrails PreToolUse latency: the disk-hygiene guard
was being used as the fast "control" in that comparison, and it turned out never to have executed.

Evidence

Measured from hook attachments in ~/.claude/projects/*/*.jsonl.

Variant 1 — destructive_guard.py --mode engine-gate. All 16 recorded runs are
hook_non_blocking_error with exitCode: 1:

Failed to run: Plugin option "disk_hygiene_enabled" isn't set. Open /plugin manage to configure it, or check that the plugin's userConfig schema declares "disk_hygiene_enabled".

The recorded durationMs is 2 ms — that is Claude Code refusing to launch the hook during config
validation, before any process is spawned. python3 -c 'pass' costs ~396 ms on this host, so 2 ms
was never physically achievable for a real run.

An earlier variant of the same registration shows a second, distinct registration bug:

Failed to run: Hook command references ${CLAUDE_PLUGIN_DATA} but only ${CLAUDE_PLUGIN_ROOT} is available for skill hooks (${CLAUDE_PLUGIN_DATA} is plugin-only).

Variant 2 — destructive-guard.sh. All 57 recorded runs are hook_non_blocking_error with
exitCode: 1:

Failed with non-blocking status code: <3>WSL (2444932 - Relay) ERROR: CreateProcessCommon:818: execvpe(/bin/bash) failed: No such file or directory

The command resolved to the Windows WSL bash.exe relay, which has no /bin/bash. Its 878 ms is the
cost of failing, not of guarding.

Impact

• The destructive-operation guard provided zero protection over the whole measured window.
• Both failure modes are non-blocking, so there is no operator-visible signal — the guard's absence
  is indistinguishable from the guard allowing the operation.
• Invoked directly, bypassing the broken registration, the guard does run and is genuinely fast:
  destructive_guard.py --mode engine-gate against a real payload measured 181 ms, 1 process, 0
  external spawns. The logic is fine; only the registration is broken.

Sequencing note

The registration carries a Bash|PowerShell matcher, so repairing it will add this guard to every
Bash tool call. On Windows that adds load to an already-contended process-spawn path. Land the
guardrails spawn-count reduction (see the linked issue) before or alongside the repair.

Not fixed here

Deliberately out of scope for the guardrails latency work — filed so it is not lost. Needs an owner
for the disk_hygiene_enabled userConfig declaration and the bash-resolution path.

Related

• repo-hygiene: destructive-guard PreToolUse hook inert on Windows — bash resolves to WSL relay, fail-open #992 (closed) — repo-hygiene: destructive-guard PreToolUse hook inert on Windows — bash resolves to WSL relay, fail-open. Same WSL-relay failure mode; independently corroborates variant 2.

[kyle-sexton]

This was generated by AI during triage.

Triage — needs-info

What we've established so far:

• Both failure signatures you quoted match real historical defects, and both already have fixes and CHANGELOG entries in the current plugin sources:
  • Variant 1 (Plugin option "disk_hygiene_enabled" isn't set): fixed in disk-hygiene by commit f40e99499988dcfbed5bd301c434eec943bbf383 (fix(disk-hygiene): resolve kill switch by reading user settings directly #1242, "resolve kill switch by reading user settings directly"), released in disk-hygiene 0.9.0. At HEAD, hooks/hooks.json's exec-form args no longer thread ${user_config.disk_hygiene_enabled} through argv at all.
  • The ${CLAUDE_PLUGIN_DATA} is plugin-only skill-hook registration bug predates disk-hygiene's plugin-level/skill-level guard split (commit e14f21ef, feat(disk-hygiene): split guard registration — plugin-level engine gate delivers kill switch + data-root #1123): the guard now runs as a plugin-level hooks/hooks.json hook, where ${CLAUDE_PLUGIN_DATA} is confirmed available per the current hooks docs (https://code.claude.com/docs/en/hooks, "Reference scripts by path" — both exec and shell form export CLAUDE_PROJECT_DIR, CLAUDE_PLUGIN_ROOT, and CLAUDE_PLUGIN_DATA on the spawned process).
  • Variant 2 (WSL relay execvpe(/bin/bash) failed): fixed in repo-hygiene by commit a83d1748 (fix(repo-hygiene): destructive-guard fail-open on Windows — shell-form hook launch + jq fail-closed degraded mode #1006), released in repo-hygiene 0.4.6 — the destructive-guard hook now declares shell form with shell: bash specifically to stop PATH-resolving to the WSL relay. Current repo-hygiene is at 0.7.1, several releases past the fix.
  • The plugin caches on this machine are already at the fixed versions: disk-hygiene/0.9.0 and repo-hygiene/0.7.1 (both present alongside older cached versions under ~/.claude/plugins/cache/melodic-software/).
• I could not corroborate the WSL-relay error text (CreateProcessCommon:818) anywhere in this machine's retained session logs (~/.claude/projects/*/*.jsonl), and the disk_hygiene_enabled error text I did find largely traces to prior triage/dogfood discussion of this same defect rather than raw hook-telemetry records I could pin to a specific cached version and timestamp.

What we still need from you (@kyle-sexton):

1. Which cached plugin version (disk-hygiene and repo-hygiene) was actually resolved during the measured window — can you confirm from the same ~/.claude/projects/*/*.jsonl hook attachments whether the failing runs' resolved command paths point at disk-hygiene/0.9.0 + repo-hygiene/>=0.4.6 (a live regression at current-fix versions — reopen as a real defect) or at an older cached version (a stale-cache artifact, already resolved by upgrading)?
2. If you can isolate one representative failing hook-attachment record (its durationMs/timeout and the exact resolved command path), pasting it here would settle this without further guessing.

[kyle-sexton]

This was generated by AI during triage.

Triage — resolving needs-info by verification instead of by waiting

The outstanding needs-info questions asked the reporter to pin the resolved plugin version for the measured window. Rather than leave the item stalled on an answer only telemetry archaeology could give, I verified the current sources at HEAD directly. Both reported failure signatures are structurally fixed there, which settles disposition regardless of how the window's question resolves.

Variant 1 — Plugin option "disk_hygiene_enabled" isn't set / ${CLAUDE_PLUGIN_DATA} is plugin-only. Fixed. At disk-hygiene 0.9.1 the guard is registered as a plugin-level hook in the plugin's hooks/hooks.json, in exec form, and its argv threads no ${user_config.*} value at all (grep -rn 'user_config' plugins/disk-hygiene/hooks/ returns nothing) — so the config-validation refusal has no input left to trip on. The ${CLAUDE_PLUGIN_DATA} argument is legitimate at that level: the current hooks reference (https://code.claude.com/docs/en/hooks, "Reference scripts by path") states both exec and shell form "export them as the environment variables CLAUDE_PROJECT_DIR, CLAUDE_PLUGIN_ROOT, and CLAUDE_PLUGIN_DATA on the spawned process." The plugin-only restriction the historical error names does not apply to a plugin-level registration.

Variant 2 — WSL relay execvpe(/bin/bash) failed. Fixed. At repo-hygiene 0.7.2 the destructive guard is a skill-frontmatter PreToolUse hook declared in shell form with shell: bash, and carries an in-file comment naming this exact failure mode: "exec form resolves command via PATH, which on Windows finds the WSL relay (System32\bash.exe) and the guard never launches — a silent fail-open." Per the current hooks reference, shell accepts "bash"/"powershell" and makes Claude Code resolve the interpreter itself rather than via PATH.

Scope of this claim — stated honestly. This verifies the registrations at HEAD. It does not establish which cached version resolved during your measured window, which is the question the prior needs-info comment actually asked. That question stays unresolved and is now moot for disposition: whatever ran then, the defect is not present in the shipped sources now. If hook telemetry later shows either signature recurring at disk-hygiene >= 0.9.1 or repo-hygiene >= 0.7.2, that is a live regression — please reopen with the failing attachment record and it will be treated as a real defect rather than a stale-cache artifact.

Sequencing note — carried forward, not dropped. The observation that repairing the registration adds a guard to every Bash call under a Bash|PowerShell matcher, loading an already-contended Windows spawn path, is live rather than moot now that the guard genuinely runs. That concern is already tracked in #1345 (guardrails: PreToolUse guards fail open — killed at their declared timeout), with remediation in flight on PRs #1379 and #1385. No new item filed — filing one would duplicate #1345.

Closing as already-implemented. Prior corroboration: #992 (closed), same WSL-relay mode.