Skip to main content
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), is MIT-licensed and is meant to be reworked for your own needs. Its README is the setup guide.

​
Three demos

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

The plugin is a Claude Code mod — a plugin of function hooks that runs inside Claude Code 2.1.295 or later — so the approval happens in the harness itself, without the model taking part.
  1. A hook of the plugin holds the tool call or the slash command and matches it against its rules. If nothing matches, Claude Code continues as usual.
  2. If a rule matches, the plugin creates a confirmation with POST /api/transaction/confirmation (client credentials). The action waits; nothing has run.
  3. The plugin opens a pane of its own with what is asked, the QR code Veriqa returned and the link. On a narrow terminal its status line says what it is waiting for, and a command opens the pane.
  4. The hook waits for the outcome, reading GET /api/transaction/{id}/result until the transaction ends. The action runs only on confirmed; declined, expired, refused in the pane, a confirmation from the wrong account or an unreachable host all refuse it. In a chain the pane moves on to the next approver’s code.
The person sees 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.

​
Channels of the sample

The person answers in Telegram by default — the host reads it by long polling, so the demo works on localhost. Messenger, WhatsApp and Instagram, or a page where the person picks one of these channels on the phone, need the host on a public HTTPS address: Meta delivers the answer by webhook, and the phone has to reach the page.

​
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 on 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

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 pane 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, email, a ticket.
The plugin puts a person in the loop; it is not a sandbox. The limits are listed in the sample’s README. The engineering side of the scenario is on Approving AI-agent actions.