Development record
The guard registry names no recursive delete and nothing wires guard check into unattended runs: On abcd v0.9.0, abcd guard check answered allow for rm -rf /tmp/x, command rm -rf $S/x, rm -r ./scratch and find . -name x -exec rm {} \; (the form without check is refused as unknown). In an unattended run one such command raised a permission prompt that stalled the run for about 111 hours; a registry entry plus wiring the check into sub-agent runs would have failed it in seconds.
issueresolvedmajoriss-2609300536290307
The guard registry names no recursive delete and nothing wires guard check into unattended runs: On abcd v0.9.0, abcd guard check answered allow for rm -rf /tmp/x, command rm -rf $S/x, rm -r ./scratch and find . -name x -exec rm {} \; (the form without check is refused as unknown). In an unattended run one such command raised a permission prompt that stalled the run for about 111 hours; a registry entry plus wiring the check into sub-agent runs would have failed it in seconds.
Frontmatter
| id | iss-2609300536290307 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2609300536290307-the-guard-registry-names-no-recursive.md
open on GitHub ↗ · commit history ↗
mentions1
- dcn-26103013090398612026-10-30 — A find that deletes each match with rm and no recursive flag (find . -name x -exec rm {} \;) is not a guard hazard: it removes only the files the find names, one at a time, the same everyday delete dcn-2609280000000003 allows as rm -rf $(find ...), and a blocker there would teach sessions to route around the guard (adr-42, a mistake filter). Decided by the technical facilitator on delegation while judging iss-2609300536290307.