Independent OpenClaw reporting, releases, guides, and community coverage
OpenClaw News

OpenClaw Plugin Approval Gates Fail Closed

OpenClaw now fails closed for plugin tool gates, tightening approval decisions across Gateway, embedded mode, and file transfer flows.

Filed under Posts 3 min read Updated Aug 12, 2026
OpenClaw Plugin Approval Gates Fail Closed

OpenClaw merged a P0 approval hardening change early Sunday that closes several ways plugin tool gates could grant execution authority without a valid, bound approval.

The merged pull request, fix(approvals): fail closed plugin tool gates, targets a sensitive boundary: when a plugin asks to run a tool, what exactly counts as permission to proceed? The answer is now much stricter. Timeout, malformed decisions, mismatched approval IDs, stale verdicts, and request-disallowed approvals no longer release the gate.

Source: OpenClaw PR #103932

What Changed

The PR says plugin tool gates had three remaining routes to execution authority without a valid approval. A legacy timeoutBehavior: "allow" option could execute after a timeout or unavailable reviewer. A trusted but malformed or disallowed verdict could be treated as approval. The node policy runtime could also return allow-once without atomically consuming that one-shot authority.

The fix establishes a tighter final invariant: only an exact allow-once or allow-always verdict, permitted by the request and bound to the parked approval ID, may release a plugin gate.

That means OpenClaw now:

  • Fails closed for timeout, missing, malformed, mismatched, and request-disallowed plugin decisions.
  • Keeps timeoutBehavior as a deprecated API field, but ignores it at runtime.
  • Binds plugin.approval.waitDecision results to the requested approval ID.
  • Consumes node-policy allow-once before returning execution authority.
  • Tightens file-transfer approval parsing at the final dispatch boundary.

Why It Matters

Approval systems are only useful when the runtime treats ambiguity as denial. If a plugin can inherit stale authority, treat malformed data as approval, or continue after a reviewer disappears, the approval prompt becomes more theater than control.

This change is especially important for file transfer and Gateway plugin paths because those surfaces sit close to real operator data and remote actions. The PR preserves explicit approvals while removing the old permissive fallback behavior.

For existing plugin authors, the compatibility note is blunt but manageable: plugins can still send the legacy timeoutBehavior field, but setting it to allow no longer grants authority after timeout.

Verification

The PR reports 173 focused tests across agent E2E, embedded mode, Gateway matrix, and file-transfer policy coverage. The maintainers also ran source-blind behavior validation against the production file-transfer policy, where deny, null or timeout, missing, and malformed verdicts produced zero node calls.

That is the right shape of proof for this kind of change. The key question is not whether approvals still render; it is whether every ambiguous path stops before execution.

The exec-host askFallback cutover is intentionally left for follow-up work because a separate authorization transaction refactor is in progress. For now, OpenClaw's plugin gate behavior is meaningfully safer: no valid approval, no tool execution.

Daily Briefing

Get the Open-Source Briefing

The stories that matter, delivered to your inbox every morning. Free, no spam, unsubscribe anytime.

Join 45,000+ developers. No spam. Unsubscribe anytime.