Approval queue

For actions that aren’t a flat no but aren’t a free yes — the agent asks the operator, and waits.

Not every sensitive action should be denied outright. Some — building a container, editing a certain protected category — are fine if the operator says so, now. The approval queue is how the gate turns “I can’t decide this alone” into a real question put to the operator, and then blocks until there’s an answer.

How an approval happens

When the gate hits an approval-eligible action, it issues an approval request and pauses inline:

  gate decides "approval required"
        │
        ▼
  POST  /v1/operator-authority/approvals      ── creates a pending request
        │
        ▼
  poll  /status  every 2s  (up to a timeout, default 600s)
        │
        ├── operator approves  ─▶ gate returns ALLOW, the action runs
        ├── operator denies     ─▶ gate returns DENY
        └── timeout / surface down ─▶ UNAVAILABLE ─▶ treated as DENY

The operator sees and answers these in the dashboard’s Agent Authority Approval Queue — the enforcement plane for approval-required actions named in HARD RULE 11. The agent’s action simply cannot proceed until that queue records a decision.

Until recently the dashboard’s Plans and Approval Queue panels showed only pending rows, so a request vanished the moment it was decided. As of 2026-06-19 they keep decided items as history — pending first, then approved / denied with a status badge and who decided it — so the queue is a record, not just a to-do list.

Two things get approved

The queue carries two related but distinct kinds of request:

Action approvals. A specific command or protected-path edit — for example a build/recreate command (HARD RULE 6) caught by the policy’s approval-required command list.
Task-plan approval. The middle tier for code changes. Rather than approving one write at a time, the operator approves a plan; that grants the task-approved token into the worktree’s scope manifest, and subsequent code writes under that plan pass the gate. The gate’s denial message even tells the agent how: submit a brief, get it approved in the dashboard’s “Plans Awaiting Approval” panel, then retry.

Why approve a plan, not each write

Approving every individual file write would be unworkable — the operator would drown in prompts. Approving a plan once, and letting the resulting token unlock the writes that belong to it, keeps the human in the loop at the level a human can actually judge: the intent of a change, not its keystrokes. The token is the durable record of that yes, and it lives in the scope manifest with an expiry.