approvals

The approvals command group is the human side of workflow checkpoints — the "keep one door open" principle as a first-class primitive. A workflow that produces something risky or publishable (an AI-written article, a bulk data change) can gate the final action behind a human: it files an approval request and stops. You list what's waiting, read it, and approve or reject. On approve, the stored action runs in-pod.

Usage

machina approvals list    [--project <id>] [--all] [--json]
machina approvals approve <request-id> [--project <id>] [--json]
machina approvals reject  <request-id> [--project <id>] [--json]

Flag	Purpose
--project, -p	A specific project (defaults to the selected project).
--all, -a	(list) Include already-resolved requests.
--json, -j	Machine-readable output.

The flow

producer workflow ──> request + Slack ask ──> human ──> approve/reject
                                                       │
                                  approve: stored action runs in-pod

1. A producer workflow composes a request (title, preview, and what should run if approved), saves it, and posts the ask to the pod's Slack channel.
2. A human sees it (Slack or approvals list) and decides.
3. approve/reject run the pod's resolution logic — approve dispatches the stored action; reject just records the decision. Machina checks the request status before resolving it. Requests that have already been approved or rejected are skipped.

$ machina approvals list

              Approval requests — pending
┏━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━┳━━━━━━━━━━━━━━━━━━┓
┃ Request    ┃ Title                    ┃ Status  ┃ On approve, runs ┃
┡━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━╇━━━━━━━━━━━━━━━━━━┩
│ a1b2c3d4e5 │ Publish: Flamengo x Vasco│ pending │ publish-article  │
└────────────┴──────────────────────────┴─────────┴──────────────────┘

$ machina approvals approve a1b2c3d4e5
Request a1b2c3d4e5 approved.
  action dispatched: publish-article

TIP

Resolution logic lives in the pod, not the CLI. Any surface — this CLI, the Studio, an MCP agent — resolves a request through the same pod-side logic, so the guard rails (double-resolution check, dispatch recording) apply no matter where you approve or reject from.

Gating your own workflow

To add a human checkpoint to your own workflow, a request needs: a title and preview to show the approver, what should run if approved (a workflow name + inputs), and a Slack notification with the ask. The provisioning kit below includes a reference implementation of these steps.

An actionless request (no action workflow specified) is also valid — a pure human acknowledgment gate.

Related

• loop — the harness loop's needs_review is the same principle at the conversation level; approvals brings it to any workflow.
• Provisioning kit — docs/harness-loop-kit/nodes.py in the machina-cli repo, for wiring the request side into your own workflow.