# Smart Approval vs client-side permission prompts (/blog/smart-approval-vs-client-side-permission-prompts)

![Illustration: A small friendly robot with a round camera-eye head carries a tiny door frame strapped to its back like a backpack, while ahead of it stands a plain unmarked low garden gate of bare wooden slats in a fence, and a human hand above the gate waits with a round stamp.](/blog/smart-approval-vs-client-side-permission-prompts/hero.webp)

Client-side permission prompts, such as Claude Code's auto mode and Codex's Approve for me, are configurable guards that run inside one client before it executes a tool. Smart Approval is a gate between the tool call and execution on CoreSpeed, with one plain-English policy for every agent and client on the team. They overlap, and they sit in different places.

**One client vs every client**

|                | Client-side prompt                                         | Smart Approval                                                                |
| -------------- | ---------------------------------------------------------- | ----------------------------------------------------------------------------- |
| Where it runs  | inside one client, before it executes                      | between the tool call and execution on CoreSpeed                              |
| What it covers | that client's actions, shell and files included            | writes made through CoreSpeed, from any client                                |
| Rules          | per client; managed settings where offered                 | one org policy in plain English; member text only stricter                    |
| Verdicts       | allow or block; prompts from matched rules                 | Allow, Ask, Deny, with Ask as its own verdict                                 |
| Who answers    | whoever is in the session; headless needs a hook you build | the caller or the owner of the agent or key, in Slack, email or the dashboard |
| Record         | the client's own logs                                      | the activity trail, with held and denied outcomes                             |

They overlap, and they sit in different places. Most teams run both.

## How do client-side permission prompts work? \[#how-do-client-side-permission-prompts-work]

Claude Code's auto mode runs a classifier before each tool call. It is configurable: you can describe your trusted infrastructure, add rules of your own in plain prose, and push them to every developer through managed settings. Codex's Approve for me does something similar with a reviewer agent and its own policy file. Both cover everything that client does, including shell commands and file edits on the machine.

When the guard needs a person, it asks whoever is in the session. Run the client headless and a question nobody answers becomes a deny. You can build a hook that forwards those prompts to Slack, and people do. It is code you write and keep running for each agent.

If your agents are coding agents on your team's laptops, use these guards. Nothing in this post replaces them for local actions.

## How does Smart Approval work? \[#how-does-smart-approval-work]

Smart Approval sits between a tool call and its execution on CoreSpeed. You write a policy in plain English, as sentences. Every write your agents make through CoreSpeed is judged against it; reads are never gated. The verdict is Allow (runs, logged), Ask (held, a card goes to a person), or Deny (refused, with the reason when a human denied).

Calls your policy never mentions fall to a default behavior: Relaxed runs them, Balanced runs them unless destructive and then asks, Strict asks for every write, Lockdown refuses every write. Written rules beat the default. Two guards sit above every verdict: low confidence becomes Ask, and an Allow that looks like prompt injection becomes Ask. A failed evaluation goes to a separate Ask or Deny setting. No failure path lets a write run.

The policy itself reads like this, taken from the docs:

```text
Sam handles support. Replies to customers who have written to us first are fine.
Ask me before anything goes to a public channel or an external company, and before any refund over $100.
Never post on our behalf about pricing, funding, or anything that reads like a product promise.
```

An admin writes the org policy, which is the ceiling. A member can add text that only makes things stricter for their own calls. Every save is a new version with history, and Test policy runs a hypothetical call through the same evaluation without executing anything. The [approvals page](/docs/approvals) has the full reference, and the [launch post](/blog/introducing-smart-approval) shows the flow end to end.

## Where do the two differ? \[#where-do-the-two-differ]

| Concern        | Client-side prompt                                             | Smart Approval                                                                 |
| -------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Where it runs  | Inside one client                                              | Between the tool call and execution                                            |
| What it covers | That client's actions, local ones included                     | Calls made through CoreSpeed, from any client                                  |
| Rules          | Per client; managed settings where the vendor offers them      | One org policy; member text only stricter                                      |
| Verdicts       | Allow or block from the classifier; prompts from matched rules | Allow, Ask, Deny, with Ask as its own verdict                                  |
| Who answers    | Whoever is in the session; headless needs a hook you build     | The caller, or the owner of the agent or key, in Slack, email or the dashboard |
| Record         | The client's own logs                                          | Activity trail, with held and denied outcomes                                  |

Three differences carry the weight. The first is scope. Auto mode's rules apply to Claude Code; Codex keeps its own; a support bot built with an SDK and a nightly job have none unless you build it. The gate covers all of them with one rulebook, because it sits where the tool call executes.

The second is Ask as a verdict. Write "refunds over $500 need my approval" as a rule in a classifier that answers allow or block, and the large refund is blocked; the agent is told why and tries another route, and you clear it with an approval stated in the conversation. In Smart Approval, Ask freezes the call. The $1,200 refund waits for a click, the $40 one runs, and the approved arguments are the arguments that run, exactly once.

The third is someone to answer. The card reaches the member the agent works for, in Slack, by email or on the dashboard. The agent gets a receipt and waits on `manage__approval_wait`. Whichever channel decides first wins.

## When is the client-side guard the right choice? \[#when-is-the-client-side-guard-the-right-choice]

Pick the client-side guard when the actions you care about are local. Shell commands, file edits, and tools from other MCP servers never pass through CoreSpeed, so Smart Approval never sees them. Pick it when one person runs one client and a prompt in the session is where they want to be asked. Pick it when the vendor's managed settings already give your organization the control it needs.

Keep it on even when you add the gate. The security notes on the [MCP server page](/docs/mcp) say to keep client confirmation on for writes when several servers are connected, because fetched content can carry instructions aimed at the agent. The two compose: the client asks about the local action, the gate judges the write that goes to Stripe or Slack.

## When is a gate in front of the tools the right choice? \[#when-is-a-gate-in-front-of-the-tools-the-right-choice]

Pick the gate when more than one client is in play, or when an agent you built has no permission prompt of its own. Pick it when "ask a human" has to be a first-class answer rather than a block the agent routes around. Pick it when the person who should decide is away from the session, and the decision has to land with the rest of the team's activity.

The limit is the same as the strength. The gate judges only calls made through CoreSpeed. It is off until an org turns it on at Dashboard → Approvals, it is in public beta, and a new organization has no policy and no gate.

## FAQ \[#faq]

**Do I have to choose one?**
No. Client-side guards cover local actions; Smart Approval covers writes through CoreSpeed. Most teams run both.

**Does Smart Approval see shell commands or file edits?**
No. It sees only tool calls made through CoreSpeed. Those stay with the client's own guard.

**Can an agent approve its own call?**
No. The member who made the call, or the owner of the agent or API key that made it, decides. Admins see every card, but seeing is not deciding.

**What happens if the judge times out?**
A separate setting decides Ask or Deny, with Ask as the default. No failure path lets a write run.

**Does every action pause?**
No. Reads are never gated. Writes are judged. The actions your policy names pause; on Balanced, an ordinary unmentioned write runs.