OpenClaw Main Fixes False-Success Updates and Misleading Health Output

OpenClaw has merged five CLI corrections for a dangerous operational pattern: the command looked successful while the requested outcome had failed, the output stream was invalid, or fresher failure evidence was hidden.

The fixes are on main; they are not proof that an installed package contains them. Operators who drive updates, health checks or plugin maintenance from automation should identify a containing build and retest exit codes, stdout and warning handling before trusting the pipeline.

What changed

Interpretation: human-readable warnings do not repair automation semantics. For a consequential command, exit status, machine output and diagnostic precedence must all describe the same outcome.

Dirty checkout now means a failed update

PR #117452 addresses source installations. openclaw update already refused to alter a dirty checkout and printed Update blocked, but returned success. A scheduler or deployment wrapper could therefore record the old revision as upgraded and continue to restart or validate the wrong code.

After adopting a containing build, stage a disposable dirty checkout, run the supported update command and assert all three facts: no mutation, a non-zero status and an actionable diagnostic. Then repeat with a clean disposable checkout. Do not manufacture this condition in the production tree.

JSON must stay JSON during failure

PR #117487 separates terminal restoration from reserved machine output. Escape sequences appended to stdout are harmless in an interactive terminal but make a JSON document invalid precisely when a parser most needs the failure payload.

Test configuration-path, schema and other machine-output commands through the same non-interactive wrapper used in production. Capture stdout and stderr separately, force a harmless configuration failure, parse stdout strictly and verify terminal-control bytes are absent. Never “fix” consumers by stripping arbitrary escape-looking text from JSON; that can hide further corruption.

Fresh health evidence must beat stale state

PR #117410 fixes precedence in verbose health and deep status output. A channel could appear healthy, configured or linked even when the fresh active probe in the same Gateway snapshot failed. A selected account could also hide failure on a sibling account.

Health automation should identify the account it tested, distinguish static configuration from live reachability and fail on the fresh probe result. Run acceptance with one healthy test account and one deliberately unreachable endpoint; prove the report does not flatten both into the selected account’s state.

Plugin maintenance now reports what it knows

PR #117357 keeps actionable plugin discovery and manifest warnings in Doctor output instead of allowing an all-clear summary to overwrite them. PR #117333 makes targeted plugin updates reject missing, ambiguous and untracked owners rather than returning success.

These are separate boundaries. Doctor tells you whether the installed plugin surface is credible; targeted update proves the requested owner exists before mutation. Automation should treat warnings according to an explicit policy, but it must never discard them before that decision.

Acceptance checklist

For the first containing build:

1. record the exact revision and current update mechanism;
2. assert dirty-checkout update refusal is non-zero and non-mutating;
3. parse machine stdout strictly on both normal and fatal paths;
4. run deep health with mixed account outcomes and preserve account identity;
5. create a harmless malformed plugin fixture and confirm Doctor reports it;
6. request an update for a synthetic missing target and require non-zero status; and
7. confirm the equivalent valid paths still succeed.

Do not use real credentials in diagnostic fixtures. Preserve redacted command, status and revision evidence when investigating an older false success.

Evidence and limits

The official merged PR and commit records supplied by the OpenClaw repository collector establish the failure modes and landed corrections. Direct GitHub extraction was unavailable and web search was blocked by the configured provider’s credit limit, so implementation claims remain attributed to upstream. OpenClaw Academy did not run these commands against an upstream source checkout.

Bottom line

A warning followed by exit 0 is not a successful operation, stale configuration is not a live health result, and JSON containing terminal-reset bytes is not machine-readable output.

Move only to a confirmed containing build, then test the failure path your automation actually consumes. The useful proof is not that the CLI printed something sensible to a human; it is that status, stdout and diagnostics agree under failure.