fix(security): bind install warning approvals

This commit is contained in:
Jesse Merhi
2026-08-10 16:08:51 +10:00
committed by jesse-merhi
parent 7412828da8
commit 7cf4e84584
18 changed files with 406 additions and 60 deletions
+10 -8
View File
@@ -154,12 +154,13 @@ non-interactive direct CLI commands can use `--acknowledge-install-policy-warnin
That flag is consumed by the first warning in one command; a later warning
fails closed and requires interactive review.
Gateway `plugins.install` clients receive structured warning details and may
make one explicit retry with `acknowledgeInstallPolicyWarning: true`. That
approval is consumed by the first warning. OpenClaw evaluates that same staged
scan again before allowing the acknowledged warning to continue. A block from
that evaluation, or a warning from any later package or dependency scan, stops
the request before commit and returns its own details. Other Gateway-backed and
automatic installs remain blocked on warnings because they have no
make one explicit retry with the returned `acknowledgementToken` as
`installPolicyWarningAcknowledgement`. The Gateway consumes that server-issued
token once and only for the same install request and resolved artifact. OpenClaw
re-evaluates the staged source and continues only when the warning is unchanged.
A block, a changed warning, or a warning from a later package or dependency scan
stops the request before commit and returns its own details. Other Gateway-backed
and automatic installs remain blocked on warnings because they have no
operator-confirmation flow. When an equivalent direct plugin or skill command
exists, use that command to review and approve the warning. Otherwise, change
`security.installPolicy` to return `allow` for the reviewed request, then retry
@@ -167,8 +168,9 @@ the managed flow. Neither `--force` nor the deprecated plugin install/update
flag `--dangerously-force-unsafe-install` approves a policy warning. Plugin
`before_install` hooks run later, and only in OpenClaw processes where plugin
hooks are loaded, so use `security.installPolicy` for operator-owned install
decisions instead. The flag does not override a block or policy failure.
It also does not bypass `before_install` hook blocks.
decisions instead. `--acknowledge-install-policy-warning` does not override a
block or policy failure. Neither acknowledgement nor the deprecated flag
bypasses `before_install` hook blocks.
See [Skills config](/tools/skills-config#operator-install-policy-securityinstallpolicy)
for the shared `security.installPolicy` exec schema used by both skills and
+5 -4
View File
@@ -202,10 +202,11 @@ every approved warning is re-evaluated before continuing.
The flag is consumed by the first warning in one command; a later warning
fails closed and requires interactive review.
Gateway `plugins.install` clients receive structured warning details and may
make one explicit retry with `acknowledgeInstallPolicyWarning: true`. The first
warning consumes that approval. OpenClaw evaluates that same staged scan again
before allowing the acknowledged warning to continue. A block from that
evaluation, or a warning from any later package or dependency scan, stops the
make one explicit retry with the returned `acknowledgementToken` as
`installPolicyWarningAcknowledgement`. The Gateway consumes that server-issued
token once and only for the same install request and resolved artifact. OpenClaw
re-evaluates the staged source and continues only when the warning is unchanged. A block, a
changed warning, or a warning from a later package or dependency scan stops the
request before commit and returns its own details. Other
Gateway-backed and automatic installs remain blocked on warnings because they
have no operator-confirmation flow. Use an equivalent direct plugin or skill