Approve or deny a workflow approval step
Project lead · Automate the work
Why this matters
Status, stated plainly: approval gates are partially built. The database schema, the REST endpoints, the MCP tool and the UI all exist. The executor does not yet persist the approval token or suspend execution, so a workflow run that reaches an approval step is marked Failed rather than waiting for you. This is tracked upstream as WF-08. The failure announces itself — a structured approval_not_supported error code naming WF-08 — but if your team relies on approval steps to keep humans in control, that control does not exist yet.
Nothing about WF-08 has moved at any release check from v0.5.12 to v0.5.20. In the same period workflows gained a full visual editor, trigger filters, template autocomplete and an activation warning. Everything around the gate was rebuilt; the gate was not.
Steps at a glance
1. Understand what does and does not work
You can author a workflow with an approval step. You can see approval UI. The CLI has an approve command. What you cannot do is have a run pause, wait for your decision, and then continue — it fails at that point instead.
The distinction matters because everything visible suggests the feature works. It looks finished from the outside.
2. Do not put approval gates in workflows yet
This is the important consequence for anyone running agents with oversight rules. The approval gate is the natural place to enforce them — work that needs human sign-off should not proceed without a human. Buzz cannot enforce that for you yet.
Until it can, human-in-the-loop enforcement in Buzz is by convention, not by system. That is a real gap and it should be named in your project design rather than assumed away. See Run a project with agent oversight levels.
3. Use the manual approval pattern instead
The workable substitute, until the executor lands:
Have the agent produce its output and stop, posting the result in the channel and explicitly asking for a decision. Give it a standing instruction that it does not proceed past that point without a human reply. Make the approval itself a message in the channel — it is a signed event, so it is a durable, attributable record of who approved what and when, which is most of what the gate would have given you.
This is weaker than a system-enforced gate in exactly one way: an agent can ignore its instruction, and nothing stops it. Supervise accordingly. See Supervise agent activity.
4. Recognise a run that failed at an approval step
A run that stops at an approval step shows as Failed rather than Waiting. It also says why: the run carries the machine-readable error code approval_not_supported with a message pointing at WF-08. On builds before v0.5.12 the same run failed with no explanation at all.
Knowing this saves an afternoon of debugging a workflow that is written correctly. If a run fails unexpectedly, read the error code before touching the workflow — the editor will not flag an approval step as a problem, because as far as authoring is concerned it is a valid step.
5. Watch for the fix
This is tracked as WF-08 and described upstream as next in line — the infrastructure is there, the wiring is not. When it ships, this guide changes from a warning to a procedure, and the manual pattern in step 3 becomes the fallback rather than the method.
The trajectory is worth reading correctly, and it has now repeated often enough to plan around. v0.5.12 made the failure visible without making the feature work. v0.5.18 rebuilt workflow authoring around it — editor, filters, template variables, activation warnings — and still did not make it work. Buzz ships observability first, then surface, then semantics; "visible failure" and "well-authored failure" are both intermediate states, not progress toward this particular fix. Read a release note about workflows as evidence about authoring until the executor is named explicitly. See Where Buzz is heading.
Check it after each new release before you change how you work.
Verified against Buzz v0.5.20 · Updated 2 Sep 2026