Show HN: UnixClaw – A Mac Mini AI assistant in one line of bash, no OpenClaw
1–4 of 4 posts
Re: Show HN: UnixClaw – A Mac Mini AI assistant in one line of bash, no OpenClaw
#2Author 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.
Re: Show HN: UnixClaw – A Mac Mini AI assistant in one line of bash, no OpenClaw
#3The .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.
Re: Show HN: UnixClaw – A Mac Mini AI assistant in one line of bash, no OpenClaw
#4The .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…
Author here. Good points.
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.