Author here. Now renamed to UnixClaw. We wrote small C CLI tools that bridge Unix pipes to native macOS apps — Calendar, Reminders, Contacts, iMessage, email. Combined with toast (our LLM CLI), the whole assistant is one line:
imessage bot 'toast "You are the executive assistant"'
No daemon, no plugin registry, no Python. Config is three text files: .persona, .tools, .crumbs. Toast works with BYOK (Anthropic, OpenAI, Cerebras, etc.) or locally via toasted on Apple Silicon at ~100 tok/s.
The NemoClaw announcement (https://news.ycombinator.com/item?id=47427027) has great discussion about whether more layers fix OpenClaw's security problems. Our take: security comes from having so little code you can read all of it in an afternoon.
Happy to answer questions about the architecture.
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.
2 comments
[ 3.3 ms ] story [ 17.5 ms ] thread