Chock runs your coding agent inside the operating system's own sandbox, in a throwaway copy of your project, under a policy the agent cannot edit.
Every turn, tool call and approval goes into a session log you can read afterwards. The log is append-only and hash-chained, so an auditor can check it without trusting the agent or us.
Linux & macOSNo way to turn the sandbox offEvery turn logged
# can this machine contain a session$ chock doctor# store a credential$ chock login --provider aiand$ chock run "add a test for the parser"Why Chock
A coding agent runs commands, writes files and wants to reach the network. Most harnesses ask the agent to be careful. Chock puts what it may do outside the agent's control.
Every tool call runs inside your operating system's sandbox, on a copy of your project, so your real files are never changed by the agent. If a sandbox layer can't be applied, the tool call doesn't run, and there is no option to turn the sandbox off.
Chock records each turn, tool call, approval and cost in a session log. You can read it afterwards and see what the agent did and what it cost. The decision that allowed an action is written before the action runs.
What the agent is allowed to do is a file in your project, chock.zon. The agent can read it and cannot edit it. If an action needs your approval and nobody answers, the action is refused.
The sandbox
Chock uses the sandboxing built into Linux and macOS. Run chock doctor to see which protections are on for your machine, and what is lost when one is not.
macOS gives no bind mount and no usable system call filter, so Chock does not list those two layers on macOS. The driver reports only what it has proved.
Every tool call, held
no privilege on the host
a throwaway copy of your project
the filesystem, held by the kernel
31 calls killed, 2 read by argument
your tool call, in a copy of your project
zig build redteam checks a canary set before and after a real session, and answers "did it break out" as a value. Grading a transcript by hand is how a real escape gets argued away. Two models have been run against it, and the one fault found is closed on both platforms. Read the threat model.
For security and platform teams
Your developers are already running coding agents, on their own machines, next to production credentials. Nothing admits a session, nothing enforces what it may do, and nothing records what it did that you did not have to take on trust.
Chock puts the three controls you already require of a service around an agent: a sandbox it cannot switch off, a policy it cannot edit, and a log it cannot rewrite. At review time that gives you attribution. Establish which commits came from an agent, and the rest are human by elimination.
A log is worth what the agent cannot go around. Every tool call in Chock goes through the sandbox, so there is no unrecorded path to take.
Ten harnesses were read at the source. The three that sandbox at all mount the whole filesystem into it, and not one keeps a tamper evident log, so who approved what cannot be answered afterwards.
chock sessions verify finds an edit in the middle and names it.chock sessions seal signs the head of the chain. A software key, a smart card key, or a card key with the card's own statement that it never left the card. An unsealed log never passes.The chain
01 · built
The agent reaches your repository through one act and no other.
02 · built
A named person approves that act, and the answer is logged.
03 · soon
A signature on the commit, so the agent set is cryptographic rather than procedural.
04 · soon after
The forge attests the push as a third party.
Each link closes what the one before leaves open. The first two are in the harness now, and the other two are the next things we build, not a someday list. The roadmap says where each one stands.
You set the ceiling once and every project inherits it. A project's chock.zon can narrow what you allow and cannot widen it, a session can narrow its own rules while it runs, and subagents inherit the narrower answer. No repository can opt itself out.
There is no flag, environment variable or failure path that runs a tool call outside the sandbox, so a developer who is blocked cannot relax the ceiling to get moving. Zed, for comparison, offers a Run Unsandboxed button when its sandbox will not start.
Where this stops
Attribution covers the sessions that ran under Chock, so it is worth what your rollout covers. Sealing is only as good as your key custody, because whoever holds the key can sign a record. The log says what an agent did, not what it could have done. There is no remote attestation and no hardware root of trust, and getting one policy onto a fleet is a file you place on each machine today, not a product.
Comparison
We compared Chock with three other harnesses by reading their source code, not their documentation. Each column names the commit we read and the date we read it. Four rows of nine are here.
| What is compared | Chockthis project | Zed5a9b955, read 2026-09-05 | OpenCode012c2f5 (v1.18.11), read 2026-08-21 | oh-my-pi9350b799, read 2026-08-21 |
|---|---|---|---|---|
| Tool calls inside the operating system's sandbox | Every one of them. | The terminal and the fetch tool. Reading, writing and deleting a file run in process. | None. Their SECURITY.md calls the permission prompt a user interface feature with no isolation behind it. | None anywhere in the tree. |
| What a tool call can read | A minimal mount tree. The credential store is never mounted, and the environment is scrubbed. | The mount is the whole root, read only. Nothing scrubs the environment, so every token in the parent shell arrives with it. | The whole machine. | The whole machine. |
| Turning the sandbox off | There is no switch. A layer that fails to apply fails the tool call. | The Linux failure path offers a Run Unsandboxed button, so fail open is a choice a person can make. | There is nothing to turn off. | There is nothing to turn off. |
| What a rule is matched against | The act a call performs, and the directory the binary came from. A git shim does read the argument vector, and the documentation says the shim stops a mistake and does not stop an attack. | Regular expressions over the command text, with chained commands parsed across 14 shells. A wrong parse is a way through. | The tool's input: the command text, the path, the URL. | A regular expression denylist of dangerous commands. Writing the argument into a variable first walks past it. |
HoldsIn partNot there
A fair note
The other harnesses have years of work behind them and do far more than Chock, which is pre-alpha. This table compares one thing: what a tool call can reach.
Read the full comparisonFeatures
The rest of the harness: how work is scoped, what an agent keeps between sessions, and where a session runs.
Set rules per project in chock.zon, with organisation-wide rules on top. An agent can tighten its own rules during a session, and never loosen them.
Read the docIf your project has a flake.nix, the agent gets the tools from your dev shell and nothing else. It can ask you for more if it needs them.
Read the docAn agent can split work across subagents. Your project sets how many it can start and how deep they can go.
Read the docAn agent can keep notes from one session to the next. They are stored outside your project, so your repository stays clean.
Read the docAdd your own tools as WebAssembly modules. Each one runs in a sandbox of its own with no network, and reaches neither your project nor the workspace.
Read the docSessions run in a background daemon, so they keep going when you close the terminal. chock serve puts a browser in front of it.
Read the docGetting started
Four steps, under five minutes.
Step 1
Take a build for Linux or macOS from the downloads page, or build it yourself with Zig 0.16 and zig build.
Step 2
Run chock doctor. It applies each sandbox layer for real and tells you which ones hold here, before an agent runs anything.
Step 3
Run chock login --provider aiand to store a key. Name your providers in ~/.config/chock/config.zon: ai&, Anthropic, or any OpenAI-compatible endpoint. Chock reads that file and never writes it.
Step 4
In your project, run chock run "add a test for the parser". Bare chock opens the full screen interface and asks you for the task there.
# what holds on this machine$ chock doctor# store a key$ chock login --provider aiand# run a task$ chock run "add a test for the parser"# the same task, with no subcommand$ chock -- add a test for the parser# the interface, which asks for the task$ chockA task typed on the line goes after --, so chock fix the parser is refused. A mistyped chock rnu that quietly became a task would spend your money on a typo. echo "fix the parser" | chock works too.
Whether you want to use Chock, help build it, or back where it is going, we want to hear from you.
Found a way out of the sandbox? Read SECURITY.md first, then report it through GitHub's private vulnerability reporting or by email to hello@lilithsemi.com. Never a public issue.