A useful approval workflow lets routine preparation proceed while holding a consequential action for a specific decision. In OpenClaw, that requires identifying the execution surface, effective policy, and reviewer path. A request to “ask before acting” is not proof that every write is gated.
1. Define the business decision before selecting a control
Consider an illustrative supplier-update workflow: read a request, prepare a proposed CRM change, and ask an operations lead before updating the supplier record. The approval should identify the record, old and new values, supporting evidence, and destination account. Preparing the proposal and applying it are separate permissions.
Specify what invalidates the decision: a different record, changed values, expired authority, or a newer version of the underlying data. Require fresh review when those conditions change. These are implementation requirements for your workflow, not a claim that OpenClaw automatically binds every business-system write to a reviewed preview.
2. Map each action to its actual enforcement point
OpenClaw distinguishes callable tools, instructional skills, and runtime plugins. Tool policy controls availability; host exec approvals govern command execution. Use a matrix like this during design, then replace each proposed control with observed behavior from your deployment.
| Action | Control to validate | Acceptance evidence |
|---|---|---|
| Read approved supplier data | Read-scoped integration identity and tool access | Reading succeeds; a write attempt fails. |
| Prepare a proposed change | Draft-only workflow stage | The proposal exists; the supplier record is unchanged. |
| Run a gateway or node command | Effective host exec policy and host approvals | A harmless unapproved command is held or denied on the intended host. |
| Write through a CRM connector or browser | Integration-specific approval and credential controls | Direct and alternate write paths cannot bypass the required decision. |
| Resume a staged workflow | Configured checkpoint and controlled resume authority | Denial prevents the downstream action; approval applies only the intended change. |
3. Do not confuse asking, automatic review, and full access
The official permission-mode reference says host exec mode ask runs allowlist matches and asks a human on misses. It does not mean every command prompts. Mode allowlist runs matching commands and denies misses; auto can let an automated reviewer allow an eligible execution, deny it, or escalate to a human. Automatic review therefore does not satisfy a requirement for human sign-off on every action.
Full mode skips ordinary policy prompts. Separate strict inline-evaluation checks can still require review, but documented full-permission Gateway sessions and qualifying elevated-full execution can skip the host approval path. Review session permissions and host policy together instead of treating a single configuration field as the complete answer.
Inspect the execution target using the documented approvals commands: openclaw approvals get --gateway or openclaw approvals get --node with the node identifier. Use openclaw exec-policy show for local policy inspection, and inspect relevant session overrides separately. Confirm the installed version supports the behavior you intend to rely on.
4. Keep non-exec writes inside the approval design
A host-command approval is not evidence that a separate messaging tool, browser session, or SaaS connector will ask before writing. Identify the control on each route. Restrict unused routes, limit integration credentials, and keep preparation separate from execution. If the integration cannot enforce the required gate, retain manual execution rather than describing the workflow as approval-protected.
The same approvals documentation describes durable MCP tool grants for supported Gateway-hosted Codex runs. Their scope is an agent, configured server, and tool, with any arguments. That is materially different from approving one supplier change. Review durable grants and remembered session decisions when testing whether a new action will prompt.
5. Decide what happens when nobody is available
For ordinary exec prompts, askFallback controls behavior when the approval UI is unreachable or the prompt times out; its documented default is deny. Do not assume fallback settings create a universal queue for later review.
The current documentation gives gateway-host scheduled runs a specific path: approvals go to connected approval clients, such as the Control UI or supported apps, not chat channels. With a reviewer surface connected, the run waits; without one, the request is denied immediately. Node-host automation exec remains headless, without those approval cards.
For eligible isolated automation runs, Always allow can create a standing grant tied to the agent, automation, job configuration, and exact operation. Substantive job changes invalidate it; some commands still require review each time. These grants default to lasting until revoked. Define ownership, expiry where configured, and revocation checks. Standing authorization is not a fresh human decision for every occurrence.
6. Use workflow checkpoints deliberately
Lobster is an optional, separately installed official plugin for repeatable pipelines with approval checkpoints. A paused workflow saves its continuation and returns a resume token; it can resume without rerunning earlier steps. Place the checkpoint before the consequential write and make downstream execution conditional on approval.
The documented limitations matter: the tool is disabled in sandboxed tool contexts, and resume tokens are not bound to an OpenClaw user or session. Possession permits resume by a caller allowed to use the tool. Protect that authority and validate reviewer identity in your surrounding process. A checkpoint is not automatically a two-person authorization system or an organization-wide approval service.
7. Accept the workflow only after negative tests
Have the workflow owner and platform operator run a disposable evaluation, recording the version, effective settings, reviewer decision, and target-system result. The following are acceptance tests to perform, not test results from a customer deployment.
- Deny the proposed update and verify no write occurred through any enabled route.
- Disconnect approval clients and verify the scheduled run's documented failure behavior.
- Change the proposed values after review and verify your integration demands a new decision.
- Revoke standing or durable authority, account for active-session behavior, and verify subsequent access.
- Simulate an uncertain write response and reconcile the target record before retrying to avoid duplicate actions.
Keep approval ownership explicit
OpenClaw's security model assumes one trusted boundary per gateway. Approval prompts do not establish isolation between adversarial users. Name the business approver, technical control owner, and recovery owner; preserve decision evidence under your retention policy. The useful outcome is a demonstrable boundary around one business action, not an unqualified promise that the agent always asks.
Sources and further reading
- OpenClaw: exec approvals, MCP grants, and automation standing grants
Checked October 13, 2026 - OpenClaw: permission modes
Checked October 13, 2026 - OpenClaw: tools, skills, plugins, and access controls
Checked October 13, 2026 - OpenClaw: Lobster workflow checkpoints and limitations
Checked October 13, 2026 - OpenClaw: security and trust boundaries
Checked October 13, 2026
Research-assisted writing by Santuri. Technical statements are grounded in the sources above, checked on the dates shown. Deployment requirements depend on your environment and installed version. Workflow examples are illustrations, not customer case studies.
Planning a deployment? Start with our enterprise OpenClaw guide and business workflow examples, or review our deployment approach.