Skip to content

Screens / Approving and controlling

Approvals inbox

One place where people decide what agents asked to do, each decision tied to the exact change.

For: Approvers: the second person who must agree before an agent's change is applied.

Markdown

3 ways to lay it out

1. List and detail

Pick it when: The default: approvers work through requests one after another.

A list of requests grouped by what they need from the viewer on the left, the selected request in full on the right.
  • Approval queueProRequests grouped by what they need from the viewer, soonest to expire first.
  • Approval requestProWhat changes, where, what it touches, whether it can be undone, and a hash that ties the decision to that change.
  • LockedFreeA person who can't decide sees why on the button, for example on their own request.
  • Change hashProThe sha256 of a change, the same in the browser and on the server, so an approval can be checked where the change runs.
  • Change set reviewProA request that is many record edits, each kept or dropped; Apply sends only the kept ones, with their hash.
Install list and detail

Pro and Premium items need a licence key; free ones install as they are.

2. Board by what it needs

Pick it when: Several agents and many requests, where approvers triage by state: needs me, waiting on others, decided.

Three columns of request cards: needs you, waiting on someone else, decided.
Install board by what it needs

Pro and Premium items need a licence key; free ones install as they are.

3. From an email or a phone

Pick it when: Approvers aren't in the app: the run pauses and the approval waits for them.

A compact approval page: the change, what it touches, and Approve and Deny at the bottom.
Install from an email or a phone

Pro and Premium items need a licence key; free ones install as they are.

Rules that matter most here

Already covered elsewhere

Brief for a coding agent

Paste this into the agent that builds the screen. The docs MCP server returns the same text from get_screen.

Build an approvals inbox with Candor UI: a place where people decide what agents asked to do.
Start from the approvals-inbox template (approvals-inbox-claude for the Claude Agent SDK) or compose ApprovalQueue and ApprovalRequest yourself.
ApprovalQueue groups requests by what they need from the viewer, soonest to expire first; ApprovalRequest shows what changes, where, what it touches and whether it can be undone.
Tie each decision to the exact change with its hash (changeHash, which gives the same hash in the browser and on the server): if the change is edited, the earlier approval no longer applies.
A person can't approve their own request; keep the button and wrap it in Locked so it says why.
Show a decision only after the server has recorded it, never an optimistic one.
Neither Approve nor Deny is pre-selected.
For approvers away from the app, use approve-from-anywhere: email an id, not a link, and decide on a compact page.
Read the ai-approval-ui and durable-agent-approvals patterns for the flow.

Start from the "List and detail" layout: A list of requests grouped by what they need from the viewer on the left, the selected request in full on the right.
Candor items: approval-queue (https://candor.themethodic.com/docs/approval-queue.md), approval-request (https://candor.themethodic.com/docs/approval-request.md), locked (https://candor.themethodic.com/docs/locked.md), change-hash (https://candor.themethodic.com/docs/change-hash.md), change-set-review (https://candor.themethodic.com/docs/change-set-review.md).
Install: npx candor-ui add approval-queue approval-request locked change-hash change-set-review
Read each item's docs before using it and take its props from there; don't guess them. Pro and Premium items need the person's licence key, which they add with `npx candor-ui key <key>`; don't ask for it.