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.
We renamed to UnixClaw — too many NoClaw namespace collisions.
On the .tools gap: you wouldn't put `rm` in .tools. The tools are purpose-built — `kal` talks to Calendar.app via EventKit, `rem` talks to Reminders.app, `contacts` talks to Contacts.app. None of them can do anything outside their domain. If you did want file deletion, you'd write a safe version that moves files to a recovery folder instead.
On the Gemini trick of disabling its own guardrails: `chmod -w .tools` by the human means toast can't modify its own permissions. The AI can only call what you've allowed, and it can't change what's allowed.
The invocation-level concern is real for general-purpose commands. Our answer is: don't give it general-purpose commands.
.tools is also directory-specific — toast walks up the tree from cwd. So your assistant handling iMessages can have a different permission set than a coding project. Least privilege, scoped by context.
reply