← NEWS DESK
security advisory

OpenClaw Main Makes System-Agent Approvals Execute the Exact Frozen Operation

A merged fix removes post-approval model inference: the verified, hash-bound persistent operation now executes directly and only once.

Independent reporting and tested guidance for OpenClaw operators · Editorial standards

OpenClaw has repaired a broken human-approval boundary in the delegated system agent. A proposal could be frozen as a persistent operation, bound to a stable hash and shown for approval—but accepting that hash did not apply the frozen operation. The old path discarded it, emitted a synthetic approval message and asked the model to infer what to do in a second turn.

PR #119389 removes that second inference step. After exact hash verification, OpenClaw now passes the already-approved operation to the persistent-operation executor and consumes the approval authority before execution.

This fix is on main. The upstream record does not identify a containing package, so do not infer inclusion from an older installed version.

Why this is a security boundary, not a UI bug

Approval is meaningful only when three identities remain the same:

  1. the operation the agent proposed;
  2. the operation the operator reviewed; and
  3. the operation the system applied.

The prior flow preserved the first two through a hash, then broke the chain by asking a probabilistic model to reconstruct the third. The next turn could return a different directive, return nothing or fail. Even a carefully worded prompt cannot make that rerun the immutable action a human approved.

The merged path uses the authoritative { operation, hash } pair already owned by the approval boundary. A wrong hash remains a no-op. A repeated callback remains a no-op. The operation is cleared from both pending stores before application, so a failed write does not leave reusable approval authority behind.

Interpretation: this is the correct ownership model. Humans approve typed effects, not an instruction asking a model to remember the effect later.

Who should prioritise the fix

Prioritise a containing build if the system agent can propose persistent configuration changes or other durable operations in your environment. The risk is highest where operators treated the approval display as proof that the exact shown mutation would execute.

Until updated:

  • do not use delegated approval for consequential persistent writes;
  • apply reviewed changes through a deterministic operator-controlled path instead;
  • reconcile any previously approved proposal against actual persisted state; and
  • never blindly retry an approval whose outcome is uncertain.

A missing change is not evidence of no side effect, and a successful-looking chat turn is not proof that the frozen operation ran.

Safe acceptance test

Use an isolated temporary state directory and a harmless configuration key:

  1. queue one proposal and record its displayed operation and hash;
  2. submit a wrong hash and prove no state changes;
  3. approve the exact hash and prove the exact typed value is persisted;
  4. replay the same approval callback and prove it is a no-op;
  5. force the deterministic executor to fail and prove approval authority is not reusable; and
  6. inspect the transcript and audit trail to confirm no second model turn selected the effect.

The upstream canary exercised a temporary configuration change and reported wrong-hash rejection, exact application, duplicate no-op and one model turn. OpenClaw Academy did not reproduce a persistent write against a live Gateway.

What this does not prove

The change does not independently validate every operation type, approval UI, delivery route or post-write verification path. It fixes the handoff after approval. Operators still need separate evidence that proposals are rendered accurately, hashes bind canonical data, authorization reaches the right operator and the underlying executor validates its input.

Adjacent messaging handoff and Gateway approval-bus changes are explicitly outside this PR’s scope.

Collector IDs 38616 and 38544 identify the merged PR and landed commit.

Bottom line

An approval should collapse uncertainty, not trigger another model guess. Stage a containing build until a wrong hash does nothing, the exact frozen operation applies once, duplicate callbacks do nothing and failure cannot resurrect consumed authority.

THE RECEIPTS

Claims should survive the click.

Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.
  1. 01Apply approved system-agent proposals exactly once — PR #119389
  2. 02Landed approval fix — commit f0a7497

THE OPERATOR BRIEF

One useful email when the signal earns it.

Release impact, security changes and repository intelligence. No daily sludge.