Nice. I've been thinking about something tangential: using the same hook mechanism to guide the agent toward better tools, not just block bad ones.
Claude Code sometimes issues Bash commands for things it could easily do with builtin tools (e.g., shelling out to grep when it has a dedicated Grep tool). A hook that catches those and nudges the agent back — "you already have a tool for this" — could improve session quality without blocking anything.
I suspect there's a lot of overlap with what you've built: parse the command into tokens, run it against rules, decide. The difference is the output is "redirect" instead of "deny." Have you thought about non-blocking rules that warn or suggest rather than reject?
Warn mode is the easy win and probably where I'd start. Redirect is more interesting but you're handing the agent a rewritten command it didn't ask for, which could be surprising in ways that hurt more than help.
I built a thing. Relevant if you use Copilot or Claude Code in autopilot mode.
Copilot's hook system lets you intercept commands before they run, but it ships without any. No rules, no protection. If you don't install a hook, everything goes straight through.
I kept thinking about this after an agent ran rm -rf in one of my sessions.
So I wrote HAL. It sits in the hook, checks every command against a set of rules, and blocks the destructive ones. git reset --hard, rm -rf /, docker system prune -a that sort of thing. It knows --force is dangerous but --force-with-lease is fine. It knows rm -rf node_modules is safe but rm -rf src isn't.
You might say "I just won't use autopilot" or "I'll review each command myself." That works with one session. It doesn't work with several running in parallel.
And the thing that asks "allow Bash?" every time trains you to click yes without reading...
Also it parses commands as tokens, not strings. So git commit -m 'fix rm -rf bug' doesn't false-positive.
Rules are YAML files, not code. About 400 lines of Python total. Covers git, filesystem, Docker, AWS and Azure out of the box.
"Just use a deny list" is the other obvious response. You could. You'd need to write every rule yourself, maintain it, and accept that string-matching rm -rf will flag git commit -m 'fix rm -rf bug' as dangerous. Plus, this enables shared rules across our company’s engineers/teams
Nice. I've been thinking about something tangential: using the same hook mechanism to guide the agent toward better tools, not just block bad ones.
Claude Code sometimes issues Bash commands for things it could easily do with builtin tools (e.g., shelling out to grep when it has a dedicated Grep tool). A hook that catches those and nudges the agent back — "you already have a tool for this" — could improve session quality without blocking anything.
I suspect there's a lot of overlap with what you've built: parse the command into tokens, run it against rules, decide. The difference is the output is "redirect" instead of "deny." Have you thought about non-blocking rules that warn or suggest rather than reject?
Warn mode is the easy win and probably where I'd start. Redirect is more interesting but you're handing the agent a rewritten command it didn't ask for, which could be surprising in ways that hurt more than help.
Yeah, I’ve redirected manually to some success but nothing hook based yet. I need to put some plumbing together to try these ideas out.
I built a thing. Relevant if you use Copilot or Claude Code in autopilot mode.
Copilot's hook system lets you intercept commands before they run, but it ships without any. No rules, no protection. If you don't install a hook, everything goes straight through.
I kept thinking about this after an agent ran rm -rf in one of my sessions.
So I wrote HAL. It sits in the hook, checks every command against a set of rules, and blocks the destructive ones. git reset --hard, rm -rf /, docker system prune -a that sort of thing. It knows --force is dangerous but --force-with-lease is fine. It knows rm -rf node_modules is safe but rm -rf src isn't.
You might say "I just won't use autopilot" or "I'll review each command myself." That works with one session. It doesn't work with several running in parallel.
And the thing that asks "allow Bash?" every time trains you to click yes without reading...
Also it parses commands as tokens, not strings. So git commit -m 'fix rm -rf bug' doesn't false-positive.
Rules are YAML files, not code. About 400 lines of Python total. Covers git, filesystem, Docker, AWS and Azure out of the box.
pip install openhal && hal install
Open source, contributions welcome https://github.com/otherland/hal
"Just use a deny list" is the other obvious response. You could. You'd need to write every rule yourself, maintain it, and accept that string-matching rm -rf will flag git commit -m 'fix rm -rf bug' as dangerous. Plus, this enables shared rules across our company’s engineers/teams
How does this compare to nono or SafeHouse?
Good question. If your threat model is “Claude does something dumb I’ll regret” HAL is enough and way less friction (one tool does one thing)
Ok. This is interesting. I like how simple and lite it is. Is the goal to keep this only for coding agents?