Skip to main content

confirm_action

Renders a confirm/cancel card asking the user to approve a destructive action. Returns immediately with an interaction_id; the user’s click arrives on the next turn via interaction replay. This is the anti-hallucination cornerstone for destructive operations. The flow is:
  1. LLM calls confirm_action({ ..., commit_token }) — gets back an interaction_id, not a result.
  2. User clicks Yes/No in the card; the server persists the choice.
  3. On the next turn, the tool’s original result is rewritten to { status: 'submitted' | 'cancelled' | 'expired', result: { confirmed: true|false } }.
  4. Before the destructive call, the LLM must call commit_action with the same commit_token. Only then is the destructive call allowed.
A misbehaving LLM cannot bypass step 4 — commit_action is server-validated against persisted approval.

Parameters

Returns

Call from your own custom tool

The cleanest pattern is a single tool that handles both turns. On turn 1 it asks; on turn 2 (after the user clicks) it gates and executes.

What the user sees

Why the gate cannot be skipped

commit_action is validated on the server: it only returns ok: true after the user has actually clicked Confirm in the card. The LLM cannot create or fake that approval — so calling commit_action before showing the card always fails.

Notes

  • Always registered.
  • Scoped to the calling subscriber (or owner in preview).
  • The card is rendered automatically by the chat UI and the deployed widget — no UI changes required from your tool.