Repository navigation
fix(disk-hygiene): the clean skill's PowerShell belt is gone after --resume, so a manual-lane delete runs unprompted #9853
Description
Problem
The /disk-hygiene:clean skill-frontmatter belt is the only gate on PowerShell deletion spellings in the Windows manual lane. The always-on engine gate defers on any command that does not name the engine. plugins/disk-hygiene/skills/clean/reference/safety-model.md (the paragraph on the kill switch's two surfaces) says the belt is registered "for the rest of the session after the skill is invoked" and that "only the session's end clears it".
A live probe on Windows shows the belt is not registered after claude -p --resume <id>, which starts a new process on the same session id.
Evidence (melo-desk-001, native Windows, Claude Code 2.1.309, disk-hygiene 0.43.21, headless --permission-mode auto, CLAUDE_CODE_USE_POWERSHELL_TOOL=1)
- One process (two sequential stream-json messages): the PowerShell
[Microsoft.VisualBasic.FileIO.FileSystem]::DeleteFile(<path>, 'OnlyErrorDialogs', 'SendToRecycleBin')call logged beltask, rulepowershell-deletion-spelling, and landed inpermission_denials. The file survived. - Turn 1 scan, then
--resumeturn 2 with the same approval: the same call logged no belt decision (engine-gateentries only) and no denial. The file was recycled. - A second, independent run: turn 1's PowerShell engine call logged both a
beltand anengine-gatedeny. After two--resumeturns, turn 3's PowerShell engine call logged anengine-gatedeny only, with nobeltentry.
Only headless claude -p --resume was probed. Interactive claude --resume, --continue and /clear were not.
Full table: the #5609 comment of 2026-10-24.
Open question for the owner
Which gate should cover PowerShell deletions in the manual lane once the process that invoked the skill has ended?
- A. Widen the always-on PowerShell hook's
ifpatterns inhooks.jsonto cover the deletion spellings, at a cost to unrelated sessions. - B. Have a SessionStart
resumehook re-arm the belt when the transcript shows/disk-hygiene:cleanwas invoked. - C. Document the limit and have the skill require the delete in the same process as the approval.
Also correct the safety-model claim whichever option is chosen.
Done when
- The chosen gate is live, with a test, or the limit is documented.
-
safety-model.mdstates the belt's lifetime as observed, with a verification record.
Activity
github-actions commentedon Oct 24, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
#9853 (comment)
I understood the report as follows. The clean skill's PowerShell belt is not registered after
claude -p --resume, so a manual-lane delete can run without a prompt. The recorded decision picks option D: a resume notice plus corrected safety-model claims. It settles the open question, so I'm asking nothing further. The decision comment names #10091 as the implementation.Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 25, 2026
Decision recorded.
This was generated by AI. The owner answered this issue as Q111 in the HITL Backlog session on 2026-10-25, replying "go w/ recommendations" to the full option set below. The ledger records it at
.work/backlog-to-zero/interview-checklist.md(Q111).Decision: D. A resume notice comes from the existing SessionStart entry. On
source: resume, when the per-sessionclean-invokedmarker exists, it tells the model to stop all deletes and overwrites until the user re-types/disk-hygiene:clean. That re-registers the skill-frontmatter belt. The stale "Not probed: Windows PowerShell" claims insafety-model.mdandunsupported-platform-handoff.mdget fixed in the same change.Options the owner was shown:
ifpatterns. Every session gets an ask on eachRemove-Item,Set-Contentor>.Why B can't be a SessionStart re-arm: SessionStart output can carry only
additionalContext,initialUserMessage,sessionTitle,watchPathsandreloadSkills, and none of these registers a hook (hooks: SessionStart decision control). A plugin'ssettings.jsoncannot shippermissions.askrules (plugins reference). Enforcement after a resume therefore needs B's always-on per-call gate. The owner chose D over it.Implementation: #10091.
melodic-automation-lanes commentedon Oct 25, 2026
Not admitted to the issue lane yet: open pull request #10091 is for it.
kyle-sexton commentedon Oct 26, 2026
This was generated by AI.
Carrying the rest of #5609 here, so one change owns the verification record in
plugins/disk-hygiene/skills/clean/reference/safety-model.md. The owner answered this issue's design question as Q111 on 2026-10-25: option D, "go w/ recommendations" (fix the stale safety-model and handoff claims, plus a resume notice from the existing SessionStart hook keyed on asession_idmarker). #5609's four-part record for hookaskis already on main (safety-model.md:711-736); two pieces of it are stale and belong in this fix:safety-model.md:716-717) with the 2026-10-24 result on disk-hygiene: prove the apply --execute guard holds in every permission mode #5609: on Claude Code 2.1.309 the PowerShell-laneaskholds within one process and is lost after--resume; the engine'sapply --executestays hard-denied on PowerShell.safety-model.md:711-716), qualified "within one process", naming the resume exception and pointing at this issue's resume notice.safety-model.md:736) away from "the PowerShell-tool probe tracked in disk-hygiene: prove the apply --execute guard holds in every permission mode #5609" (closing).