Summary
Several gateway-backed commands advertise --json, but when the gateway connection fails they emit no JSON on stdout and only write a human-readable error to stderr. This makes automation brittle because callers cannot parse the failure shape.
gateway probe --json already behaves better in the same situation: it exits non-zero but still returns a structured JSON failure object.
Environment
- OpenClaw:
2026.5.7 (eeef486)
- Node:
v24.15.0
- OS: Windows
- Install: isolated npm install of
openclaw@latest
- Profile:
imladri-sidequest-2026-5-7
- Gateway: not running for this profile
Reproduction
openclaw --profile imladri-sidequest-2026-5-7 health --json --timeout 1000
openclaw --profile imladri-sidequest-2026-5-7 gateway health --json --timeout 1000
openclaw --profile imladri-sidequest-2026-5-7 devices list --json --timeout 1000
openclaw --profile imladri-sidequest-2026-5-7 gateway probe --json --timeout 1000
Actual
These commands exit 1, stdout is empty, and stderr contains human text such as:
[openclaw] Failed to start CLI: GatewayTransportError: gateway closed (1006 abnormal closure (no close frame)): no close reason
Affected in this repro:
health --jsongateway health --jsondevices list --json
Control case:
gateway probe --json exits 1 but returns valid JSON on stdout:
{
"ok": false,
"degraded": false,
"capability": "unknown",
"timeoutMs": 1000
}Expected
When --json is requested, gateway-backed commands should return a structured JSON error object on stdout even on connection failure, similar to gateway probe --json.
At minimum, the CLI should document which --json commands are best-effort success-only and which provide machine-readable errors.
Why this matters
These commands are natural health-check and automation surfaces. A non-JSON failure path forces scripts to special-case stderr text parsing even though the command advertises JSON output.
Summary
Several gateway-backed commands advertise
--json, but when the gateway connection fails they emit no JSON on stdout and only write a human-readable error to stderr. This makes automation brittle because callers cannot parse the failure shape.gateway probe --jsonalready behaves better in the same situation: it exits non-zero but still returns a structured JSON failure object.Environment
2026.5.7 (eeef486)v24.15.0openclaw@latestimladri-sidequest-2026-5-7Reproduction
Actual
These commands exit
1, stdout is empty, and stderr contains human text such as:Affected in this repro:
health --jsongateway health --jsondevices list --jsonControl case:
gateway probe --jsonexits1but returns valid JSON on stdout:{ "ok": false, "degraded": false, "capability": "unknown", "timeoutMs": 1000 }Expected
When
--jsonis requested, gateway-backed commands should return a structured JSON error object on stdout even on connection failure, similar togateway probe --json.At minimum, the CLI should document which
--jsoncommands are best-effort success-only and which provide machine-readable errors.Why this matters
These commands are natural health-check and automation surfaces. A non-JSON failure path forces scripts to special-case stderr text parsing even though the command advertises JSON output.