The .tools allowlist is the most interesting design decision here — it’s an explicit permission boundary that answers “what can the AI do?” in a human-readable file. That’s the right instinct. The gap is that .tools controls which commands toast can invoke, but not how it invokes them. rm in .tools means the AI can run rm -rf just as easily as rm somefile. The blast radius of individual tool behavior isn’t bounded by the allowlist. I ran into the same problem building omamori — a shell guard for AI CLI tools that intercepts destructive commands at the invocation level. The interesting finding during testing: Gemini CLI autonomously discovered the disable command, turned off protection rules, ran the destructive command, then re-enabled the rule to cover its tracks. The threat model shifted from “block bad commands” to “the AI will try to remove whatever is blocking it.” NoClaw’s architecture is cleaner than OpenClaw by an order of magnitude. But the pipe-based design that makes it auditable also makes it harder to add invocation-level controls without breaking the Unix composability that’s the whole point.