> ## Documentation Index
> Fetch the complete documentation index at: https://veriqa.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Approvals in Claude Code

> A sample plugin that stops chosen Claude Code actions until a person approves them in a messenger through Veriqa: tool calls, long command cycles and costly runs.

The sample shows how Veriqa fits into a ready-made agent harness: a person approves sensitive agent
actions — not only tool calls, but also heavy runs that burn time and tokens — and every approval,
refusal and expiry lands in the Veriqa audit trail. This matters most for teams where several
developers work with agents at once.

Claude Code and development tasks are the example chosen here; the approach fits another harness
and other tasks. The sample lives in `samples/claude-code/` in the repository
([veriqa.app/source](https://veriqa.app/source)), is MIT-licensed and is meant to be reworked for
your own needs. Its README is the setup guide.

## Three demos

| Demo | What is stopped | Action type |
| - | - | - |
| A tool call | `git push` and `rm -r…` in the Bash tool | `agent-tool-call` |
| The start of a long command cycle | `/cycle`, `/cycle-chain` — typed by a person or started by the agent | `agent-command-start` |
| A costly run with an estimate | a run estimated at 1 billion input and 50 million output tokens, about 6250 USD | `agent-costly-run` |

The costly run takes **two approvers in turn** — a developer, then a manager — each from their own
messenger account enrolled beforehand. A confirmation from any other account refuses the action.

## How it works

1. A hook of the plugin matches the action against its rules. Nothing matches — Claude Code goes
   on as usual.
2. A rule matches — the plugin creates a confirmation with
   `POST /api/transaction/confirmation` (client credentials), and the call is refused for now.
3. Claude shows the QR code Veriqa returned. The plugin ships a small MCP tool that takes only the
   transaction id and returns that image unchanged, so the agent copies nothing.
4. Claude repeats the call, and this time the plugin waits for the outcome with
   `GET /api/transaction/{id}/result`. The action runs only on `confirmed`; declined, expired, a
   confirmation from the wrong account or an unreachable host all refuse it.

The person reads a wording declared on the host with typed slot values filled in — "Claude Code in
demo-shop wants to push the branch to the remote repository" — never text the agent wrote.

## Why not the harness's own "Allow" button

* **A named person.** The host checks which messenger account confirmed, not merely that someone
  pressed a button.
* **Someone other than the developer.** A chain asks a second person, so nobody signs off their own
  spending.
* **A trail outside the agent's session.** Approvals are recorded on the Veriqa host, not in a local
  transcript the same user can edit.
* **A question the agent does not write,** answered on a separate device over a channel the agent
  does not control.

For a single developer watching their own agent, the harness button is often enough; the difference
shows when several people share agents, spending or responsibility.

## Demo shortcuts

<Warning>
  Veriqa runs on the developer's machine only to make the demo quick to set up; in a team the
  approving host is a shared service. The second approver's QR code is shown in the same
  conversation for the demonstration only — Veriqa does not deliver the question to that person,
  and in a real setup the link reaches them another way: their own chat, e-mail, a ticket.
</Warning>

The plugin puts a person in the loop; it is not a sandbox. The limits are listed in the sample's
README. The engineering background of the direction is on
[Approving AI-agent actions](/docs/research/agent-approvals).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.