Pi's bash hook really blocks, but unlink slips past the guard

The test began from a narrower question than safety in general: what actually reaches the model when a hook refuses a call. Pi's documentation covered the mechanics — event.input can be rewritten in place with no re-validation, and refusals return { block: true, reason?, terminate? } — but said nothing about the result the model sees. Running a minimal extension that rejects anything matching /\brm\b/ and prefixes other bash commands with an echo marker, the author watched the session log confirm that the marker really appeared in the output, and that the rejection arrived as an ordinary error result carrying the reason string. The model then re-checked the directory with ls -la, saw the tmp files still present, and asked the user whether to continue or clean up instead of retrying endlessly.

That orderly behavior changed once the instruction was strengthened. Told that the files had to be deleted even without rm, the model avoided the blocked pattern and used unlink, which passed straight through the regex, and the author confirmed only keep.txt remained. The model also listed find -delete, perl's unlink and a python os.remove one-liner as alternatives. The author's conclusion is that being able to refuse a call and being safe are different things, and that because Pi runs extensions in-process and exposes the argument contents, stronger filters are possible — but they remain the extension author's responsibility rather than a framework guarantee.

The author also notes that a prior Japanese-language write-up already showed the refusal-and-continue core using a mock provider, whereas this run went through the real Anthropic API and additionally covered command rewriting and instruction-based bypass. The terminate: true option, parallel tool calls and a measured comparison with OpenCode's out-of-process model were left for later.