disk-hygiene: prove the apply --execute guard holds in every permission mode

[kyle-sexton]

Problem

The disk-hygiene destructive guard gates hygiene.py apply --execute with a PreToolUse hook that returns permissionDecision: "ask". Whether that ask holds is documented for some permission modes and not others:

• Probed and held (2026-09-30, Claude Code 2.1.285, Linux/WSL2, Bash tool): headless default mode denied the call; --bg default mode parked at the prompt; headless --permission-mode bypassPermissions listed the call in permission_denials and the target survived (PR feat(disk-hygiene): add model-invocable read-only audit skill #5590, comments 5916629407 and the probe table in its body).
• Not probed: an interactive session in bypassPermissions, auto mode, and the Windows PowerShell tool.
• The official docs do not name hook ask under bypassPermissions. The /permission-modes "Actions no mode auto-approves" list names ask rules, not hook ask. Upstream [BUG] Bypass permission mode resets after a PreToolUse hook returns "ask" anthropics/claude-code#37420 (closed, 2026-03) reports the prompt still appears interactively; #79356 (2.1.215, Windows, PowerShell tool, closed stale) reports a hook ask not enforced. Research record: .work/hook-ask-bypass-permissions/RESEARCH.md (memory tier, not committed).

So the only gate on the irreversible lane rests on behavior that is undocumented for two of the modes a session can be in.

Acceptance criteria

1. Probe the guard's ask on apply --execute in: an interactive bypassPermissions session, auto mode, and the PowerShell tool on a Windows fleet host. Record mode, version, tool, result and the target listing on this issue.
2. Decide whether apply --execute also needs a gate that does not depend on the permission mode (an engine-side confirmation, or a hook deny in modes where ask cannot reach a person), and implement the chosen one with tests, or record why not.
3. Add a four-part verification record (Claim, Basis, As of, Recheck) for the hook-ask-under-bypass behavior to the disk-hygiene safety-model reference, with a recheck trigger on any Claude Code changelog entry that names PreToolUse ask or bypassPermissions.

Related

• disk-hygiene: model-invocable read-only audit skill for orchestrators and subagents #5516 (owner decision A1, condition 4), PR feat(disk-hygiene): add model-invocable read-only audit skill #5590 (the read-only audit skill that motivated the probe).
• disk-hygiene: give the session belt an escape hatch and re-scope its deny-by-default to its actual threat model #3856 (session belt re-scope), disk-hygiene: PowerShell guard false-positives on read-only Export-Csv into the plugin data dir, and the workaround bypasses the guard #5226.

[kyle-sexton]

Owner decision (2026-10-01): approved the recommendation ("go with recommended", the owner's reply to the batch decision page that listed this question and its recommendation).

Question: which option for the apply --execute guard, A, B, C or D? Chosen: A, probe first. An agent runs the headless auto-mode probe on this WSL host and the PowerShell-tool probe on melo-lap-001 or melo-desk-001 via /fleet:reach, both against a throwaway dir under .work/. The interactive bypassPermissions probe is run by the owner (or by an agent only if the owner explicitly authorizes a tmux-driven session, since AGENTS.md forbids bypass mode otherwise). Results are recorded here, then AC2 is decided (record why not, or add a mode-independent gate with tests) in a PR that closes this issue.

Next: the owner names the Windows host for the PowerShell probe and runs or authorizes the interactive bypassPermissions probe. Until then needs-human is set and agent-ready is removed so no lane picks this up early. The auto-mode probe can run any time.