Playin in this sandbox isn't very fun
TL;DR;
I'm not happy with the current state of permissions and sandboxing for command-line coding agents. Clash is an attempt to build an external permissions system that is agnostic to the agent harness.
Value is produced by change
"The only safe program is one with no IO".
I normally make this joke when talking to one of my friends who is super FP pilled. The joke being that of course functional programming is safer and has less bugs, it doesn't actually interact with the outside world. In my experience, value is almost exclusively produced by doing IO[1].
I find myself feeling the same way when working with claude[2].
It can do almost anything, as long as anything means reading and generating text in a controlled environment. If you want to actually produce a lot of value with an agent, you're going to need to let it do IO. At this point, you need to decide how dirty you're going to let your agent's hands get.
Change is inherently dangerous
This week, Meta's Director of Alignment Summer Yue let an OpenClaw agent loose on her real email inbox. It speedran deleting 200+ emails while she frantically typed "stop" into a chat window that wasn't listening. She had to physically sprint to her Mac Mini and kill the process. The person whose literal job is AI safety couldn't stop her agent from nuking her inbox. If that doesn't set the scene, I don't know what does.
If you're asking yourself
"why are people giving these agents the keys to the kingdom"?
I point you towards the zeitgeist of anxiety that has been produced by the confluence of job insecurity and ai-maxing-hype-influencers assuring you that you're falling behind if you aren't running the newest 3 hour old build of openclaw.
Current state of the world
I don't feel the need to explain why sandboxing coding agents is a hot topic all the sudden.
If you want to catch up: Cursor, Codex, and Claude Code have all published their takes on agent sandboxing in the last few months.
You're locked in and none of this is composable
The convergent pattern of sandbox + high level permissions makes a lot of sense from a defense in depth perspective. Unfortunately each of these teams is only attempting to fix the symptoms of their own piece of software. None of this is holistic. If your company makes something work with claude, and then openai makes some huge advancement, well, you're out of luck! You either don't get to take part of the advancement, or you get to go back to square one and must choose between safety and productivity.
I think we can do better
Clash is an attempt to build an agent-agnostic safety harness. The idea is simple: your safety policy shouldn't be defined inside the tool you're trying to constrain. It should live outside it.
Clash sits between the agent and the OS as a plugin that intercepts tool calls via hooks before they execute. You write policy in a small s-expression language that covers three domains — command execution, filesystem access, and network access:
(policy "my-project"
(allow (exec "cargo" *))
(deny (exec "git" "push" *))
(allow (fs read "./src" *))
(deny (fs write "./secrets" *))
(allow (net "github.com")))
Policies layer: user-level defaults in ~/.clash/policy.sexpr, project-level rules checked into your repo at .clash/policy.sexpr, and session-level overrides for when you're feeling brave. Deny always wins, and more specific rules beat less specific ones. The filesystem rules compile down to kernel-enforced sandboxes, so even if the agent finds a way to be clever about it, the OS says no.
The important part is that none of this cares which agent is running. The policy is yours — it describes what you allow on your machine for this project. When you switch from claude to codex because openai dropped something shiny, your safety rules come with you. Your team checks .clash/policy.sexpr into the repo and everyone gets the same guardrails without configuring three different tools three different ways.
So far I've only built out support for claude code, but we're already working on opencode, gemini, and codex. It's still under heavy development — daily releases, rough edges, the whole deal — but we'll probably hit something stable by the end of March. I'll be writing about its development on this blog, with some more official communication coming when we at Empathic get our shit together and put up our new site.