What each agent supports
| Agent | Activity | Prompts | Terminal | Native tools | MCP | Data | ||||
|---|---|---|---|---|---|---|---|---|---|---|
| Read | Write | Edit | Delete | Search | ||||||
| Claude Code | — | — | ||||||||
| Claude Cowork | — | — | ||||||||
| Cursor | — | — | ||||||||
| Codex | — | — | — | — | ||||||
| GitHub Copilot | — | — | ||||||||
| Augment Code | — | — | ||||||||
| Pi · Beta | — | * | ||||||||
pi-mcp-adapter 2.21.0 or later. See How MCP rules identify a server.
What each column means
Activity and Prompts are what Unbound records. Terminal, Native tools, MCP and Data are where a rule can act.Why a native-tool cell is blank
A blank under Native tools means a rule does not reach that action through the agent’s own tool. Two reasons:How far a file rule reaches
The shell is covered on every agent here. A delete rule catches deletion through the shell on every agent, and through the agent’s own delete tool where it has one (Augment Code and Cursor). Claude Code, Claude Cowork, Codex, GitHub Copilot and Pi have no delete tool, so for them the shell is the route. The action you choose changes the reach. On Block, Warn and Require Slack Approval, a file rule — read, write or delete — covers both the agent’s own tool and the shell. An Audit rule reaches the shell only, so pair it with a live rule on the same family when you need both. Tool Policies has the families, and when to reach for a Custom pattern instead.How MCP rules identify a server
An MCP rule matches on the server being called, and most agents name it in the call. On GitHub Copilot and Augment Code, a rule matches a server present in that agent’s own configuration on the machine; a server missing from it is recorded rather than matched. On Claude Cowork, rules match the servers you add; Cowork’s own built-in tools are part of the app rather than servers you configure. On Pi, MCP calls reach Unbound through thepi-mcp-adapter extension, version 2.21.0 or later. A call made through an older adapter, or through a different MCP extension, is not checked, and nothing in pi says so. Pi has what is covered and how a server is identified.
Listing an agent’s MCP servers and matching an MCP call are separate things. Discovery reads an agent’s configuration to inventory its servers; the MCP column is about the moment a call is made.
What each action does on each agent
Every decision is recorded, whichever action you choose. Block and Audit behave the same on every agent; Warn and Require Slack Approval depend on what the agent can show:
A tick under Warn means the developer is asked to confirm. A tick under Require Slack Approval means the call is held while an approver answers in Slack.
Where Warn is blank the developer is not asked, and what follows differs: Codex refuses the action, Cursor runs it and passes the warning to the agent as context, and Augment Code runs it unless its own high-risk shell rules catch it first. Every one is recorded.
Augment Code cannot hold a call open for approval, so use Block there where a person must decide.
Pi cannot hold a call open for approval either. A Require Slack Approval rule asks the developer to confirm in pi instead, so use Block there where someone other than the developer must decide.
On a headless Claude Code run — in CI, or through the Agent SDK — there is nobody to prompt, so the action runs unless your organization sets headless warnings to block.
On a headless Pi run —
pi -p, or the JSON mode — there is nobody to ask, so a Warn rule blocks the action.
Use Block where an action must not happen, and Require Slack Approval where a person should decide.
Agents pointed at Unbound as a provider
Roo Code, Cline, Kilo Code, Gemini CLI and any OpenAI-compatible client connect differently: you point them at Unbound with an API key instead of installing anything alongside them. Their traffic is recorded and their spend is metered. Tool policies do not apply to them — those need one of the agents in the table above.Discovered, not yet enforced
Unbound detects these agents. Tool policies do not apply to them yet.Enforcing on one of these today
Policies are not tied to a particular agent. A rule matches on what the call is, not on which agent made it — so an agent that reports its tool calls to Unbound gets real decisions back today through the hooks API. Both expose a way to hook in. What you take on:- You write and maintain the client, including the part that turns a refusal into that agent’s own way of stopping. We publish the contract, not an installer.
- Terminal and MCP rules work. File-tool rules do not — those reach an agent’s built-in tools only for the agents in the table above. Write against the shell.
- Warn needs a confirmation step of your own. Until you build one, use Block.
- Budgets and spend limits do not apply.
If a device cannot reach Unbound, work continues by default — a check that cannot run does not stop the developer. Your organization can require the opposite, so an unreachable check blocks instead. See Settings.