fix(disk-hygiene): guard-launch detector shares the guard's interpreter, so it is blind to the interpreter fail-open

[kyle-sexton]

Problem

plugins/disk-hygiene/hooks/hooks.json declares the same literal interpreter for both wired hooks:

• :9 — the PreToolUse engine-gate guard (destructive_guard.py), "command": "python3"
• :28 — the Stop guard-launch detector (guard_launch_monitor.py), "command": "python3"

One interpreter resolution, two hooks. When python3 is absent, broken, or resolves to the
zero-length WindowsApps\python3.exe App Execution Alias stub that
plugins/disk-hygiene/README.md documents, the guard process never starts — Claude Code treats the
non-blocking result as approval, so the destructive command runs ungated. The detector that exists
to make exactly that failure visible is launched the same way and dies the same way: the
hook_non_blocking_error record is written to the transcript and never read.

The detector therefore cannot observe the single fail-open vector this plugin's own README documents
most prominently.

Why this is deferred rather than fixed in #1465

The requested remedy — a launcher whose availability is independent of the guarded interpreter — is a
design decision #1465's diff does not settle. A Python detector has no launcher independent of a
Python interpreter. The candidate designs each carry distinct cross-platform trade-offs and none is
implied by the change under review:

1. A shell/batch shim that resolves an interpreter and reports its own failure.
2. Absolute-interpreter resolution mirroring what /disk-hygiene:setup check already does for this
   exact alias case.
3. A non-Python detector.

#1465 now discloses the blind spot at all three coverage-disclosure sites (README, safety-model
reference, CHANGELOG), so the documented envelope matches what the code delivers. This issue owns
closing the gap itself.

Re-open / close trigger

Closed when both wired disk-hygiene hooks launch through a path whose availability does not depend
on the same unresolved python3 lookup, and the detector can report a guard launch failure
caused by interpreter resolution. Removing the disclosure sentences without shipping that is not a
close.

Source

Codex review finding (P1) on #1465, plugins/disk-hygiene/hooks/hooks.json:28.

[kyle-sexton]

This was generated by AI during triage.

Triage

Verification: confirmed, against the merged state of #1465 (merged, guard_launch_monitor.py and the Stop hook entry are on main).

• plugins/disk-hygiene/hooks/hooks.json declares "command": "python3" for both the PreToolUse engine-gate guard (destructive_guard.py, line 9) and the Stop guard-launch detector (guard_launch_monitor.py, line 28) — the same literal interpreter, exactly as claimed.
• plugins/disk-hygiene/README.md already discloses this exact gap and self-references this issue: "It is also wired with the same literal python3 command as the guard it watches, so the interpreter-resolution failure below — the WindowsApps alias stub, or a missing/broken python3 — takes the detector down with the guard and goes unreported (fix(disk-hygiene): guard-launch detector shares the guard's interpreter, so it is blind to the interpreter fail-open #1504)." This confirms fix(disk-hygiene): surface silent destructive-guard launch failures #1465 disclosed rather than fixed the gap, per this issue's own "why deferred" section.
• The three candidate designs (shell/batch shim, absolute-interpreter resolution mirroring /disk-hygiene:setup check, non-Python detector) are genuinely not settled by fix(disk-hygiene): surface silent destructive-guard launch failures #1465's diff — none is implied by the merged change.

Classification

• Type: Bug
• Priority: priority: medium — real, disclosed security-relevant gap (the detector is blind to exactly the fail-open vector the plugin's README documents most prominently), but already disclosed (not silently unknown) and not blocking other work or carrying a deadline.
• Target state: human-gated. Genuinely open design space among three candidate interpreter-independence strategies, each with distinct cross-platform trade-offs — exactly the "open design space" criterion for human-gated rather than a maintainer-vetoable default.

Labels applied: priority: medium, needs-human (role labels resolved from tracker defaults). priority: needs-triage cleared.

Related: #1416 (origin issue), #1465 (PR that disclosed rather than fixed this gap), #1423/#1449 (sibling fail-open fix, different vector).

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Promote to agent-ready.

Small scoped bug with a bounded blast radius and enough specification for autonomous pickup. Removed needs-human, added agent-ready.

Re-open trigger: If implementation reveals an unresolved design fork or security policy decision.