Generated from compatibility/, the same records leastgrant doctor and the README table read.

Agent support

One profile and one set of floors, whichever agent you are using that day. Every adapter calls the same judgePre and recordPost, so there is one decision path rather than one per editor — a security story that changes depending on which editor you opened is not a security story.

What differs is how much of a decision survives the trip out. These pages are the honest version of that, per agent, and they are worth reading even if you never install LeastGrant: the differences between these permission systems are real and mostly undocumented.

The two questions

Enforcement is how much of a verdict lands. Verification is what has been run to establish that. They are separate on purpose: an agent can have the best permission semantics here and still have had nothing exercise them.

The one thing to know about each

Every agent has a sharpest edge. Carrying it here rather than only on the per-agent page is deliberate: a support table read on its own is exactly where somebody forms the belief that an integration is complete.

• Claude Code — Managed policy disableAllHooks: true switches every hook off, including managed ones, with no signal LeastGrant can see. It is silently absent.
• Codex CLI — No ask verdict exists at all. On Codex, LeastGrant is a veto rather than a prompt.
• Cursor — preToolUse accepts ask and silently allows the action. Cursor logs the response as valid and merges it, no prompt appears, and the tool runs. Only allow and deny are enforced on that surface, so LeastGrant refuses a floored file action rather than pretending a person was consulted.
• GitHub Copilot CLI — No permission mode is sent, so LeastGrant cannot tell an attended run from an unattended one and records observation rather than approval. Copilot therefore learns more slowly, deliberately.
• Google Antigravity — The hook engine installs only when the server-delivered experiment flag json-hooks-enabled is true. It is per-session, not persisted, not readable and not overridable from the client, so LeastGrant cannot tell an enforcing session from an unenforced one.
• OpenCode — permission.ask is declared in the plugin types and dispatched nowhere — trigger("permission.ask" occurs zero times in the shipped bundle. Building on it would produce an adapter that appears installed and enforces nothing.

What the verification grades mean

These are not a ladder of politeness. Each one names a different thing that was done, and the distance between reading an agent's contract and reproducing its real transport is where a bug lived: LeastGrant refused every tool call on Cursor for a full release because its Windows transport prefixes a byte-order mark, and nothing short of driving that transport would have found it. Only the grades currently in use are listed below — the list is derived from the records, so a grade nobody holds does not appear.

LIVE VERIFIED

the real agent ran with LeastGrant installed and enforcement was observed happening.

UNVERIFIED

no adapter ships, or nothing has been established about it.

Adding one

An adapter is a translation layer over the shared engine, and it cannot ship without a record like the ones above: the build fails if an adapter has no compatibility file, if the conformance suite does not drive it, or if its record claims more than the runs it lists. Contributing has the shape of it.