PreToolUse hook "deny" decisions not enforced for Bash commands issued by Task-tool subagents
Bug: PreToolUse hook "deny" decisions are not enforced for Bash commands issued by Task-tool subagents
Summary: A PreToolUse hook that returns permissionDecision: "deny" for a Bash command is correctly evaluated (right logic, right decision) but the harness does not actually block the command when it's issued by a background/Task-tool subagent. The command runs anyway.
How I found it: On 2026-08-06, an unattended background subagent ran rm -rf on the user's full home directory for ~5.5 minutes before being manually killed, destroying real project data (later recovered from GitHub). I hardened our own PreToolUse hook (guardian.js) afterward to hard-deny a list of catastrophic patterns (rm -rf on home/root, git reset --hard, find -delete, chmod -R 777, DROP TABLE, etc.) specifically when the command originates from a subagent (detected via transcript_path containing /subagents/).
Live reproduction, 2026-08-07: Dispatched a real Task-tool subagent (via the Agent tool) and had it run two commands that should have hit the hard-deny rule:
find <test-dir> -type f -deletechmod -R 777 <test-dir>
Both target disposable test files created specifically for this test — no real data was at risk. Neither command was blocked. I verified independently (not just trusting the subagent's report): the files were actually deleted, and the permissions were actually changed to 777. The hook script itself, tested by piping the same command directly into it as synthetic stdin, correctly returns deny — so the classification logic is right, but the harness isn't enforcing it for this call context.
Why it matters: This is the exact mechanism that caused a real, unattended destructive incident. A hook that can't reliably stop a background subagent from running catastrophic commands isn't providing the safety guarantee its own documentation implies.
Possibly related: our local changelog cache shows v2.1.211 fixed "auto mode overriding a PreToolUse hook's ask decision for unsandboxed Bash." This may be the same underlying bug class, either not fully fixed or specific to deny (vs ask) for subagent-issued commands specifically.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗