clash

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. On Linux, rules can generate kernel-enforced filesystem sandboxes so even allowed commands can only touch the files you specify.

Three concepts

Without Clash vs. with Clash

A minimal policy

# ~/.clash/policy.star (user level)
load("@clash//builtin.star", "base")
load("@clash//std.star", "exe", "policy", "cwd", "domains")

def main():
    my_rules = policy(default = ask, rules = [
        cwd(follow_worktrees = True).allow(read = True, write = True),
        exe("cargo").allow(),
        exe("git", args = ["push"]).deny(),
        exe("git", args = ["reset", "--hard"]).deny(),
        exe("git").allow(),
        domains({"github.com": allow}),
    ])
    return my_rules.merge(base)

{
  "schema_version": 5,
  "default_effect": "ask",
  "sandboxes": {},
  "tree": [
    { "condition": { "observe": "tool_name", "pattern": { "literal": { "literal": "Bash" } },
        "children": [
          { "condition": { "observe": { "positional_arg": 0 }, "pattern": { "literal": { "literal": "cargo" } },
              "children": [{ "decision": { "allow": null } }] } },
          { "condition": { "observe": { "positional_arg": 0 }, "pattern": { "literal": { "literal": "git" } },
              "children": [
                { "condition": { "observe": { "positional_arg": 1 }, "pattern": { "literal": { "literal": "push" } },
                    "children": [{ "decision": "deny" }] } },
                { "condition": { "observe": { "positional_arg": 1 }, "pattern": { "literal": { "literal": "reset" } },
                    "children": [
                      { "condition": { "observe": { "positional_arg": 2 }, "pattern": { "literal": { "literal": "--hard" } },
                          "children": [{ "decision": "deny" }] } }
                    ] } },
                { "decision": { "allow": null } }
              ] } }
        ] } }
  ]
}

Three effects: allow auto-approves, deny blocks, ask prompts you. First matching rule wins — put specific rules before broad ones. Edits take effect immediately — no restart needed.

Quick start

1. Install clash

   curl -fsSL https://raw.githubusercontent.com/empathic/clash/main/install.sh | bash

   Downloads the latest release binary for your platform (Apple Silicon Mac, Linux x86_64, Linux aarch64). On Intel Mac: cargo install clash.
2. Initialize

   clash init

   Writes a default policy, installs the Claude Code plugin, configures the status line, and walks you through initial setup.
3. Launch your agent

   claude

   Every Claude Code session now loads clash automatically. Use /clash:status inside a session to see your policy in action.

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.

Currently, the Claude Code integration is the most mature. If you'd like to help bring Clash to another agent, contributions are welcome.

How it works

Clash integrates via the agent's plugin system. For Claude Code, a plugin registers hooks that intercept every tool call. Each invocation is evaluated against your policy and returns an allow, deny, or ask decision — before the agent executes anything.

The policy is read on every tool call, so edits take effect immediately. On Linux, allowed exec rules can generate Landlock sandboxes; on macOS, Seatbelt profiles constrain filesystem and network access at the kernel level.