Which Coding Agents Can You Actually Control, Ranked (2026)
Run agents? ACP lets you see, control, and price every tool call they make — allow/ask/deny policy, per-session cost, and a full audit log for Claude Code, Cursor, Codex, and OpenClaw, in one command:
curl -sf https://agenticcontrolplane.com/install.sh | bashGetting started → · see your first governed call → · free up to 5 agents · prefer fully on-device? add --local
Last updated: August 26, 2026.
Over the past six months we built and shipped a control integration for fourteen coding agents. Same layer, same policy vocabulary, same audit format each time. That was meant to be routine plumbing work.
It was not. The integrations came out wildly different sizes, and the reason had nothing to do with how good the agents are at writing code. It was that the fourteen are built to be controlled in fourteen different ways — and three of them are built in ways where the control you think you have silently isn’t there.
That seemed worth writing down as a ranking, because if you are choosing a coding agent, or you already have one and want to know what you can actually stop it doing, the answer is mostly decided by the agent, not by what you bolt on.
Four criteria:
- Native controls — what does the agent ship on its own, before you add anything?
- Seam depth — where can an external check intercept, and does every call go through it?
- Can it ask? — when a policy is unsure, can a human be put in the loop, or does “unsure” collapse to allow or deny?
- Silent-failure risk — if the control is misconfigured or ignored, do you find out?
That last one turned out to matter more than the other three.
The comparison
| Agent | Native controls | Seam depth | Can it ask? | Notable |
|---|---|---|---|---|
| 1. Claude Code | Permissions + settings.json |
Hook, all native tools + MCP | Yes, native | The reference implementation |
| 2. Antigravity (Google) | allow/ask/deny engine, action(target) rules |
Hook, native tools + MCP across CLI, IDE and app | Yes, native — cached Always-Allows can’t pre-empt | No tool output post-hoc |
| 3. Codex CLI | Richest in the set — approval policies, permission profiles, sandbox, requirements.toml |
Hook (default-enabled, shell only) + MCP for the rest | Yes, PermissionRequest |
Best native model, partial external seam |
| 4. DeepSeek Harness (dsh) | Approval prompts | Plugin, everything incl. Code Mode sub-calls | Yes, feeds dsh’s own prompt | Deepest single pipeline |
| 5. Muse Code (Meta) | Approval prompts | Plugin, one hook pipeline | Yes, via PermissionRequest |
Can rewrite results inline |
| 6. Grok Build (xAI) | Permission modes | Hook, native tools + MCP, fires in always-approve | No native ask |
Silently ignores Claude Code hooks |
| 7. pi (earendil-works) | None | Extension, every dispatch, no MCP layer to miss | Yes, when a UI is attached | Zero native controls, clean seam |
| 8. opencode | Permission system | Plugin, permission-routed + deny-only backstop | Yes | Backstop for unrouted tools |
| 9. OpenClaw | Plugin surface | Native plugin | Yes | — |
| 10. Cursor | Prompts; audit is Enterprise-gated | Hook, most native tools | Yes | Some built-ins don’t emit |
| 11. Hermes Agent | Hooks | In-process, native + custom skills | No, block-only | Post-hook is observational |
| 12. Prime Agent | None | Extension, inherited from pi | Reports a human is present when none is | hasUI lies in print mode |
| 13. Cline | Prompts | MCP only — no pre-tool hook | Partial | Only MCP-routed calls are seen |
| 14. Zed | Per-thread folder scoping | LLM proxy only | No | Best native scoping, no per-call seam |
The ranking is “how much of what the agent does can you see and stop,” not “which agent is better.” Zed is last here and is genuinely excellent at the thing it does do.
The three that fail quietly
Start here, because a gap you know about is a different problem from one you don’t.
Grok Build reads your Claude Code hooks and ignores them. By default it reads hook config out of your real ~/.claude/settings.json. If you have a Claude Code hook installed, Grok Build is already running it on every call — and discarding every verdict it returns. The hook fires. The log fills up. Nothing is ever blocked. We only found this by testing a deny that should have stopped and didn’t. Config compatibility is not contract compatibility, and this is the shape that costs people the most, because every observable signal says the control is working.
Cursor’s audit log is behind the Enterprise plan. Free, Pro and Team tiers get the agent but not the record. That one is at least visible on the pricing page.
Prime Agent reports that a human is present when nobody is. pi’s cleanest contribution to this whole area is the empty-chair signal: ctx.hasUI tells an extension whether anyone can actually answer a prompt, so an approval raised with nobody watching can deny instead of hanging. Prime Agent is a hard fork of pi and inherited the API — but the signal is wrong in print mode. Checking the process arguments doesn’t rescue it either, because every session is hosted in a daemon worker whose argv never shows the real mode. The result is an unattended run where the policy believes a person is there to say no.
And a third case that catches almost everyone: Codex CLI, where half the common summary is out of date and half is still true. “Its hooks are behind a feature flag” stopped being true at 0.145.0 — they are stable and enabled by default now. “Its hooks only cover shell commands” is still true on every version. Those two claims usually travel in the same sentence, so correcting the sentence wholesale breaks the half that was right. A control claim that is 50% stale reads exactly like one that is 100% current.
1. Claude Code — the reference implementation
Best for: most people, and the bar others should be measured against.
It ships a real permission system with allow/deny rules in settings.json, and a PreToolUse / PostToolUse hook that fires before and after every native tool call and every MCP call. A policy can return a genuine ask that Claude Code surfaces to a human. That combination — native controls, a complete seam, and a three-way decision — is unique in this list.
The honest limits are documented and we have written about them at length: deny rules are string patterns and command strings have many spellings, the rules are per-machine so they drift across a team, and --dangerously-skip-permissions disables the permission system entirely, hooks included. The enforcement disappears exactly when people stop watching.
2. Antigravity — the strongest native permission engine
Best for: teams that want one rule set to hold across an editor, a CLI and an app.
Google’s Antigravity is an agent-first ecosystem rather than a single tool — the IDE, the agy CLI that replaced Gemini CLI in May 2026, and extensions for VS Code, JetBrains and Zed. Its permission engine is the most expressive here: allow, ask and deny arrays of action(target) resources in ~/.gemini/antigravity-cli/settings.json, so a rule reads command(git), write_file(src/), or mcp(linter/*). Three-way decisions are native rather than bolted on.
The seam matches it. One hook registration covers native tools and MCP calls across the CLI, the IDE and the app — the same rules hold wherever the agent is running, which is the thing per-tool config usually fails to do. Two details are better than the field: an ask maps to a force_ask prompt card that a cached Always-Allow cannot pre-empt, closing the gap where a previous approval quietly answers a later question; and headless runs soft-deny natively, so the empty chair resolves correctly without an external layer teaching it to.
The honest limit. PostToolUse carries no tool output, so the post-hoc record is audit and completion only. Anything that depends on reading what a tool returned — scanning for secrets, PII or injected instructions in the result the model is about to read — has nowhere to happen. Antigravity decides well before the call and sees little after it.
3. Codex CLI — the richest native model, on a partial seam
Best for: teams that want fleet-level constraints, not just per-laptop config.
Codex has the strongest set of controls it ships itself of anything in this list, and it got there fast. A year ago the summary was “strong sandbox, coarse approvals, no extension surface.” Two of those three clauses no longer hold.
What it ships today: three approval policies (untrusted, on-request, and a full-access mode), a three-mode sandbox (read-only, workspace-write with network off by default, danger-full-access) whose boundary subprocesses inherit, permission profiles in beta with filesystem path maps and per-domain network rules, and a native hooks system covering PreToolUse, PermissionRequest, PostToolUse, compaction, prompt-submit and session events. Non-managed hooks require a one-time interactive review, hash-recorded and re-prompted on change.
Two designs are ahead of the field. approved_with_amendment lets an approval persist a prefix rule to ~/.codex/rules/default.rules, so a one-off human decision becomes reviewable standing policy instead of evaporating — we would like to see others copy it. And requirements.toml, delivered by filesystem, MDM, or the ChatGPT workspace, sets hard constraints on which approval policies, sandbox modes and profiles are even selectable. That is fleet policy, and no other agent here has it.
Headless is handled properly: codex exec defaults to a read-only sandbox and never prompts — blocked actions fail back to the model as errors it can adapt to, so every would-be ask resolves to deny rather than silently to allow.
The seam caveat, which is the reason this is #2 and not #1. The hooks are stable and enabled by default from 0.145.0 onward — the earlier codex_hooks flag was under development and off by default, and the distinction matters because writing the wrong key on the wrong build fails in opposite directions: hooks on an old build is an unknown key and the hooks stay dark, codex_hooks on a new build warns on every launch. But the hook events cover shell commands only. File edits, writes, web fetches and MCP calls are not hooked on any version. An external check on those has to come through an MCP connector, and anything beyond that is an instruction to the model rather than an interception — which the model can decline.
The other honest limits. The Guardian reviewer (--approve-for-me) is a classifier gate, and like every classifier gate its verdicts have no queryable rationale trail — fail-closed is the right default but explainability isn’t there. Compound bash -lc scripts only split into rule-checkable subcommands for linear chains of plain words, which the exec-policy docs state precisely and deserve credit for. And requirements.toml binds Codex, not the other agents on the same laptop.
4. DeepSeek Harness (dsh) — the deepest single pipeline
Best for: agents that spawn sub-work you also want covered.
dsh’s plugin system carries everything through one path — native tools, custom plugins, and Code Mode sub-calls, which is the part most integrations miss. An ask feeds dsh’s own approval prompt. Headless runs turn asks into denies by design, which is the right default and is stated rather than discovered.
5. Muse Code — one pipeline, and it can rewrite
Best for: caring about what the model reads back, not just what it runs.
Meta’s Muse Code routes native tools through a single hook pipeline, maps a PermissionRequest to policy, and lets a deny settle the native prompt. It is one of the few that can rewrite a tool result inline before the model sees it, which matters for secrets and injected instructions in returned content.
6. Grok Build — fires in every mode, including always-approve
Best for: unattended runs, once you have the right hook.
Past the silent-hook problem above, Grok Build’s own hook system is strong in a specific and underrated way: the pre-call check fires in every permission mode, including always-approve and headless. Most agents treat “always approve” as a reason to stop asking anything, including the policy layer.
Two rough edges. Grok’s tool names are its own (run_terminal_command, read_file, search_replace), so anything keying on canonical names needs a translation step or content-based rules silently miss. And Grok has no ask — an unsure policy has to resolve to allow or deny by mode. Only PreToolUse can block; post-hoc findings surface loudly but after the fact.
7. pi — no controls at all, and the cleanest seam here
Best for: the clearest illustration that these are two separate questions.
pi is built minimal-core: four tools, no approval prompts, no allowlist, no sandbox, and its docs say so plainly. Out of the box it is the least controlled agent on this list.
It is also among the easiest to control completely, because every tool dispatch flows through a typed extension pipeline — tool_call and tool_result — with no MCP layer alongside it to miss. Everything it runs goes through those two events. Native controls and controllability are close to independent, and pi is the proof.
8–9. opencode and OpenClaw — native plugin surfaces
Best for: teams already on either.
Both expose a native plugin surface with a real three-way decision. opencode’s is permission-routed with a deny-only backstop for tools that do not go through the permission system — which is an honest design for an imperfect situation, and it means the backstop can deny but not ask.
10. Cursor — good seam, gated record
Best for: Cursor teams not on Enterprise.
Cursor’s hooks mirror Claude Code’s with lowercase event names, and cover most native tools. Some built-ins do not emit hook events — we filed those rather than paper over them, and until they land, a small share of Composer’s activity is not visible to any external check. Combined with the Enterprise-gated audit log, “most” is the accurate word for Cursor’s coverage.
11. Hermes Agent — complete, but block-only
Best for: Python-native setups.
Nous Research’s Hermes runs pre/post hooks in-process across every tool including custom skills, installed with pip. The limit is the decision vocabulary: it supports block, not ask. An unsure policy blocks and routes the approval elsewhere, and the post hook is observational — it can record but not intervene.
12. Prime Agent — pi’s minimalism, minus the signal that made it safe
Prime Agent (PrimeIntellect-ai/prime-agent, around 18k stars) is a hard fork of pi that pushed the minimal-core idea further. Like pi it ships no permission prompts, no rules and no sandbox — the kernel runs with the launching user’s full access, and the extension docs list permission gates as the first example use case for the extension API rather than a built-in.
What it does ship is bounded autonomy: /autonomous takes maxTurns, maxContinuations, maxTokens and timeoutMs, and print mode reports which limit stopped the run. Those are budget throttles, not decisions — they cap how long a run goes, not what it is allowed to do. Sessions are durable branchable JSONL you can fork and rewind, which is the run’s own account of itself on the run’s own machine, not an independent record.
It ranks below pi despite the same extension seam for one reason, covered above: the inherited hasUI signal is wrong in print mode. A missing control is a known gap. A control fed a false signal is worse, because it reports success.
13. Cline — MCP only
Cline does not expose a Claude-style pre-tool hook. It does support MCP, so calls that route through an MCP server can be checked. Everything the agent does with its own built-in tools cannot. If you are choosing an agent partly on controllability, this is the architectural fact to know first.
14. Zed — the best native scoping, no per-call seam
Zed’s Parallel Agents let you run multiple agent threads at once, each with its own context, and the Threads Sidebar lets you control exactly which folders and repositories agents can access. Per-thread filesystem scoping is real and it is the control that matters most day to day. Zed is also open source, so the boundary is readable.
What parallelism changes is what a per-thread control cannot express. There is no unified log across threads — “what did my editor actually do today” has no single answer. A rule like “no thread may run rm -rf” is a cross-thread property and has to live outside the editor. Four threads at fifty turns and five calls a turn is a thousand tool calls an hour with no per-workspace ceiling. The available seam is the LLM proxy layer, which gives observation and cost attribution, not a per-call decision.
What to actually do
If you are choosing. Controllability is a real selection criterion now and it is not correlated with how good the agent is. Claude Code, Antigravity, dsh, Muse Code, pi and Grok Build expose a complete seam — every tool dispatch passes one checkable path. Codex covers shell that way and routes the rest through a connector. Cline and Zed have no per-call seam at all, and no external layer changes that.
If you already have one. Find out which of the fourteen rows you are on before you trust a control you have configured. The Grok Build case is the instructive one: every signal said the hook was working.
Re-check anything you last looked at more than a quarter ago. Codex went from coarse approvals to hooks, profiles, a reviewer agent and fleet constraints in roughly six months. On this timescale every control-surface claim has a shelf life, including the ones on this page — which is why it carries a date at the top.
Test the deny, not the install. The single most useful thing in this whole exercise was writing a rule that should stop something, then running the thing. Three of the fourteen behaved differently from their documentation. An install that reports success is not evidence.
What this doesn’t tell you
Fourteen agents, tested by us, against one control layer. Coverage claims are from our own integration work and our own verification runs — they are what we observed, not vendor commitments, and several of these agents ship weekly. The Grok Build hook behaviour is current as of this writing and is the kind of thing that gets fixed. None of this measures how well any of them writes code, which is probably why you are choosing one.
The per-agent detail sits in the coverage matrix and the controls reference, both of which we keep current as the integrations change. If you want to check your own setup rather than take ours, the check is the same one we ran: write a deny for something harmless, run it, see whether it stops.
I think of this as the harness question rather than the tool question — the framework, memory, tools and control layer are one system, and picking the agent picks most of the last one for you.