alter approvals

Read-only visibility into an application’s human-in-the-loop approvals — including multi-party (N-of-N) approval groups — and the deployment’s approval configuration.

alter approvals defaults
alter approvals list --app <app-id-or-name> [--status <status>] [--limit <n>] [--offset <n>]
alter approvals show --app <app-id-or-name> --approval <id>

Requires dashboard_approvals:read. Everything here is read-only: deciding an approval (approve/deny) is always the designated approver’s action in the wallet, never a CLI operation.

defaults

Show the deployment defaults and per-grant bounds the HITL approval system uses.

alter approvals defaults

list

List an application’s approvals, newest first. Each row carries its own status plus the derived group status and gate count — a request that requires several distinct approvers (multi-party approval) appears as one group whose status stays pending until every gate is approved.

alter approvals list --app <app-id-or-name>

# Only rows still awaiting a decision
alter approvals list --app <app-id-or-name> --status pending

• --app — the application, by ID or name (falls back to ALTER_APP_ID or the linked workspace, both UUID only).
• --status — filter by a row’s own status: pending, approved, executing, denied, expired, executed, or failed.
• --limit / --offset — pagination (1–200 per page, default 50).

All output formats emit the current page’s rows rather than the pagination envelope. When another page exists, the CLI prints the next --offset to use on stderr.

show

Show one approval with its full multi-party breakdown: every gate of the group (per-gate status, approver, decision time) and the request-rule snapshot the caller attached to the original request, if any.

alter approvals show --app <app-id-or-name> --approval <approval-id>

• --approval — any gate’s approval ID; the response always includes the whole group.

A group executes only after every gate is approved; a single denial or expiry ends the whole group.