OpenClaw merged a security-focused install flow tonight in PR #116489: external security.installPolicy commands can now return warn, giving authorized operators a deliberate review step between automatic approval and a hard block.
That distinction matters for plugin and skill installs. OpenClaw packages can carry executable behavior, and install policy hooks are one of the places where teams encode local trust rules. Before this change, a policy result effectively had to be treated as allow or block. Now there is a third state for suspicious or unusual installs that should not proceed silently but also may not deserve a permanent denial.
How The Warning Path Works
The merged PR defines the new behavior around a bounded operator acknowledgement. When an interactive CLI install receives a warn, OpenClaw shows the policy reason and findings, then requires the operator to type the exact target name before continuing.
For scripted direct CLI use, a new --acknowledge-install-policy-warning flag can approve warnings for that command invocation. The PR is careful about what that flag does and does not authorize. Each acknowledged warning is evaluated again against the staged source before installation continues, so changing source cannot ride through on a stale review.
The terminal states stay strict:
allowcontinues.warnpauses for interactive confirmation or explicit noninteractive acknowledgement.blockremains terminal.- malformed policy output, timeouts, failed policy execution, oversized reviews, and dependency-boundary failures remain terminal.
Automatic flows, system-agent flows, and Claw package flows cannot borrow authority from an ambient terminal prompt. They stop with direct-CLI recovery guidance instead.
The Security Decision
The PR includes an explicit security-owner decision approved by Jesse Merhi on August 14, 2026. The contract is that a warning is an accidental-install interlock, not a second authorization boundary. Someone who is already authorized to install executable plugin or skill code may continue past a warning for that invocation; blocked installs and failed policy checks cannot be bypassed.
That is a useful line. It keeps the warning path practical for local policy review without weakening a hard denial.
Why Operators Should Care
OpenClaw is increasingly used in multi-agent and multi-channel deployments where package installation can affect more than a single terminal session. A warning state gives teams a better workflow for borderline cases: suspicious package metadata, unusual dependency trees, unknown publishers, or local rules that require a human look before executable code is committed.
The implementation also keeps the deprecated --dangerously-force-unsafe-install flag non-authorizing. That helps prevent older bypass habits from becoming the escape hatch for the new policy model.
Verification
The PR reports 317 focused policy, CLI, and scan tests passing, plus hermetic production-installer proof against a real executable policy command. The evidence covers approved warnings, missing acknowledgement owners, real policy blocks, TTY prompt suppression, system-agent prompt suppression, and Claw package prompt suppression.
The Bottom Line
PR #116489 makes OpenClaw installs more expressive without turning review into theater. Security policies can now say "stop and look at this" while preserving the hard boundary for blocks, failures, and source changes between review and commit.