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.
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.