OpenClaw Stops Reporting Failed Work as Success in Streams and Status

Two merged changes on August 21, 2026 address the most dangerous failure shape in an operator’s stack: the system reporting success while the underlying work failed.

Streaming clients got clean completions for failed runs

PR #127662 fixes a mismatch between the Gateway’s agent execution and its OpenAI-compatible streaming APIs. A client consuming Chat Completions or Responses streams could receive a well-formed, successful completion even though the resolved agent run had failed — when the agent reported its failure in terminal metadata or an error stop reason, the stream still closed like a win.

Consumers building on the compatible API — dashboards, orchestrators, evaluation harnesses — therefore recorded successful turns that never happened. The merged fix fails the streaming response when the agent run fails, so transport outcome and execution outcome agree.

Upstream flagged the change P1 with its top review tier, proof: sufficient, and a compatibility merge-risk label; the correct reading is that some clients may now see errors where they previously saw quiet fiction.

Interpretation: this fix will surface as “new failures” in downstream metrics after upgrade. Those failures are not regressions; they are the first accurate measurements.

Operator actions

1. Inventory everything that consumes your Gateway’s streaming endpoints and add or verify failure-path handling — a client that assumed every completion implies success will now receive errors it must survive.
2. Compare post-upgrade success rates against pre-upgrade baselines with the expectation that the honest number is lower; quantify the gap rather than reverting it.
3. In alerting, distinguish stream-format failures from agent-run failures once they arrive separately.

Status reported healthy while substituting defaults

PR #127402 fixes openclaw status. When the config file failed validation, the command exited 0, printed a complete Overview table, and silently substituted built-in defaults for every invalid value — the operator’s authored settings were simply not in effect, and nothing on screen said so. The PR demonstrates with {"gateway":{"port":"abc"}}: an obviously wrong port type produced a confident, healthy-looking report.

Any automation keying off status exit codes — cron checks, container health gates, deploy verification — trusted a report that described defaults, not your system.

The merged fix surfaces the invalid configuration instead of reporting health, so the command’s verdict describes the configuration actually in force.

Interpretation: the deep issue is precedence. A liveness check that silently falls back to defaults answers a different question than the one operators ask. Post-fix, an invalid config is loud; pre-fix, it was invisible except through behavior differences.

Operator actions

1. Run openclaw status against each production environment after upgrading and resolve any newly surfaced config-validation errors — they were present before; the tool just hid them.
2. If a mystery remains where a setting “never took effect” on an affected build, check whether the config file failed validation and defaults were substituted.
3. Keep health automation on exit codes, but pair them with explicit config validation so the two can never disagree silently again.

Why these belong together

One lie lived in the API surface; the other in the diagnostic surface. Both rewarded blind trust — a parser that believed the stream, an auditor that believed the exit code. The durable lesson for OpenClaw operators is structural: wherever your automation consumes a success signal, prove at least once that the failure path produces the opposite signal. After upgrading, the honest failures you begin to see are the point.