OpenClaw Blocks Windows cmd Startup Paths That Auto-Review Could Not See

OpenClaw merged a P1 security-boundary fix into main on 27 July for Windows command execution. Automatic execution review could approve a visible cmd command even though shell startup behaviour could execute additional commands the reviewer had never analysed.

The upstream report identifies three unsafe launch shapes: registry-configured cmd.exe AutoRun commands, persistent /k sessions, and interactive shells. The merged change prevents those paths from inheriting automatic approval.

This is not evidence of a remotely exploitable vulnerability or proof that a published OpenClaw package is affected. It is evidence that the reviewer and the eventual Windows process could disagree about what would run. If Windows agents can execute shell commands, that disagreement is enough to treat the containing update as a security-relevant rollout.

Operator decision

Do not weaken approval policy to restore commands that become blocked. A newly required prompt is the boundary failing closed.

Why startup behaviour belongs inside the review boundary

An execution reviewer can only approve safely when the reviewed program and arguments describe the complete work that will occur. Windows cmd.exe complicates that assumption because startup can introduce behaviour outside the visible command line.

A registry AutoRun entry may execute when cmd starts. A /k invocation keeps the command processor alive after the supplied command. An interactive shell can accept later input. In each case, approving only the original text does not prove that all resulting commands were reviewed.

Interpretation: the correct fix is not to teach policy to trust more ambient Windows state. It is to deny automatic approval when the launch mode cannot be represented completely and deterministically to the reviewer.

This follows the same security principle as OpenClaw’s recent POSIX parser hardening: the policy layer and the execution layer must agree on semantics. The Windows issue is distinct, however. It concerns shell startup and lifetime, not escaped-newline parsing.

Safe acceptance test

Test the containing build on an isolated Windows machine using harmless commands. Verify outcomes, not bypass strings:

1. a simple, non-interactive command covered by a narrow policy still follows the intended path;
2. a plain unapproved command still denies or prompts;
3. persistent and interactive cmd launches cannot receive automatic approval;
4. shell startup state cannot add unseen work to an automatically approved launch;
5. cancelling or denying the prompt prevents execution; and
6. approval logs identify the reviewed command without exposing credentials or sensitive environment values.

Run the test through the same route your agents actually use. A parser or policy unit test does not prove that Gateway dispatch, Windows process creation and the final shell agree.

Scope and availability

The official pull request is merged, marked P1, and explicitly labelled as a security-boundary and compatibility risk. Its landed commit is eb4c6ca669b0ed49a7594611f95dfb4405b067e4.

The available primary-source packet does not provide an affected-version range, a CVE, or a release containing the commit. OpenClaw Academy therefore is not assigning any of those. A newer version number alone is not proof of inclusion: match the package or source revision to the pull request or commit.

Web retrieval of the full pull-request page was unavailable during this editorial run. The findings above are limited to the official merged PR and commit records supplied by the collector; we did not reproduce the behaviour on Windows.

Bottom line

OpenClaw’s automatic reviewer could approve a Windows cmd launch without seeing commands introduced by AutoRun or persistent and interactive shell behaviour. Main now blocks that trust mismatch.

Windows operators with shell execution enabled should adopt a confirmed containing build through a controlled update. Until then, keep those shell modes behind explicit approval and retain process isolation—the reviewer is one control, not the whole sandbox.