clash
Command Line Agent Safety Harness
Stop babysitting your coding agent, go touch grass.
[!IMPORTANT]
Clash is under heavy development. It's being used by engineers at Empathic and is quite productive, but the API is not stable and is subject to change. Please report bugs!
Agent Support
Clash is designed to be agent-agnostic — a universal safety harness for any coding agent that executes tools on your behalf. The policy language and capability model are agent-independent; only the integration layer is specific to each agent.
Claude Code is the most mature integration. The other 5 agents have protocol adapters (hook JSON parsing/formatting), extension packages, and --agent flag support throughout the CLI. Use clash init --agent <name> to set up any supported agent.
The Problem
Coding agents operate with broad tool access — executing commands, editing files, and making network requests on your behalf. Their permission models tend to be all-or-nothing: either you allow a tool entirely or get prompted every time. You end up clicking "yes" hundreds of times a session, or giving blanket approval and hoping for the best.
Clash gives you granular control. Write policy rules that decide what to allow, deny, or ask about — then let the agent work freely on safe operations while blocking dangerous ones. Rules can carry OS-enforced sandboxes (Landlock on Linux, Seatbelt on macOS) so even allowed commands can only touch the files you specify.
Quick Start
There are two ways to run clash depending on what you're doing:
Install (use clash in your day-to-day work)
curl -fsSL https://raw.githubusercontent.com/empathic/clash/main/install.sh | bash
clash init
claude
This downloads the latest release binary to ~/.local/bin/ (Apple Silicon Mac, Linux x86_64, Linux aarch64). On Intel Mac or other platforms, install via Cargo:
cargo install clash
clash init imports permissions from your coding agent's existing configuration and generates a matching Clash policy. It also installs the agent plugin, the status line, and prints next steps. Use clash init --no-import to skip policy generation and just install hooks. After init, every claude session automatically loads clash.
If you have the repo checked out, you can also use just install which registers the plugin from the local source tree instead of GitHub.
Develop (hack on clash itself)
just dev
This builds the binary and launches a one-off Claude Code session with the plugin loaded directly from source. Changes to hooks or Rust code take effect on the next just dev — no install step needed.
Policy Rules
Policies are written in Starlark (.star), a Python-like configuration language that compiles to JSON IR. Clash reads policies on every tool invocation, so edits take effect immediately — no restart needed.
You can also write policies directly in JSON if you prefer — see the Policy Writing Guide for the JSON schema.
Policy Layers
Clash supports three policy levels, each automatically included and evaluated in order of precedence:
| Level | Location | Purpose |
|---|
| User | ~/.clash/policy.json (or .star) | Your personal defaults across all projects |
| Project | <project>/.clash/policy.json (or .star) | Shared rules for a specific repository |
| Session | Created via --scope session | Temporary overrides for the current session |
| Harness | Injected automatically | Agent infrastructure access (memories, settings, transcripts) |
Note: Both .json and .star are supported. When both exist at the same level, .json takes precedence. CLI commands (clash policy allow/deny/remove) operate on policy.json.
Layer precedence: Session > Project > User > Harness. Harness default rules are injected at the lowest priority — your rules always take precedence. They allow the agent to access its own infrastructure directories (~/.claude/, <project>/.claude/, transcript dir). Disable with CLASH_NO_HARNESS_DEFAULTS=1 or settings(harness_defaults=False). Use clash status --verbose to see harness rules tagged [harness].