openclaw - 💡(How to fix) Fix [Bug]: `openclaw health --json` fails while `openclaw gateway health --json` succeeds on the same healthy gateway [2 comments, 3 participants]

Bug type

Behavior bug / CLI wrapper mismatch

Beta release blocker

No

Summary

On a healthy local gateway, the top-level CLI command:

openclaw health --json

can fail or time out even though the direct gateway health paths succeed against the same running gateway:

openclaw gateway health --json
openclaw gateway call health --params '{}'

This does not appear to be a general gateway outage. It looks like the top-level health wrapper is not equivalent to the direct gateway health path.

Steps to reproduce

1. Start a healthy local OpenClaw gateway
2. Verify direct gateway health succeeds:

openclaw gateway health --json
openclaw gateway call health --params '{}'

1. Run:

openclaw health --json

1. Observe that the top-level health command fails or times out while the direct gateway health commands still succeed.

Expected behavior

openclaw health --json should succeed whenever openclaw gateway health --json succeeds against the same configured gateway.

Actual behavior

• openclaw gateway health --json: succeeds
• openclaw gateway call health --params '{}': succeeds
• openclaw health --json: fails or times out

OpenClaw version

2026.4.24

Operating system

Ubuntu 24.04 under WSL2 on a Windows VM

Install method

npm global install

Model

N/A for reproduction

Provider / routing chain

N/A for reproduction

Additional provider/model setup details

The environment also had Azure model routing configured for agents, but this issue reproduced on the health command path itself and did not depend on model execution.

Logs, screenshots, and evidence

I ran the supported repair path first:

openclaw doctor --non-interactive
openclaw doctor --fix --non-interactive --yes

That restored the canonical gateway service, but the mismatch remained:

openclaw gateway health --json
openclaw gateway call health --params '{}'
openclaw health --json

The first two succeeded, the top-level health command did not.

I then inspected the installed bundle and found that the top-level health wrapper appears to call the shared gateway path without the same CLI caller identity used by other CLI-to-gateway commands.

A local patch to the installed health wrapper that added:

clientName: "cli",
mode: "cli"

to the gateway call made openclaw health --json start succeeding immediately, with no other environment change.

Because of that, this looks like a real CLI wrapper bug rather than just local daemon drift.

Impact and severity

This makes the main user-facing health command unreliable and misleading:

• users can see openclaw health fail while the gateway is actually healthy
• diagnostics become confusing because the lower-level health commands work
• it encourages users to misclassify the issue as gateway instability instead of a CLI wrapper mismatch

Additional information

This report is intentionally narrow and does not include separate issues I observed during the same session, such as:

• stale researcher session state
• wrong wiki/hot.md content
• plugin staging ENOTEMPTY warnings

Those looked like separate concerns and should not be conflated with this health-wrapper bug.