Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: local status/gateway status false-negative regression starts in 2026.4.24; --require-rpc and 2026.4.23 client still succeed [2 pull requests, 4 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#73535•Fetched 2026-04-29 06:18:35
View on GitHub
Comments
4
Participants
3
Timeline
9
Reactions
0
Author
DJBlackhawkDJBlackhawk
Participants
clawsweeper[bot]clawsweeper[bot]DJBlackhawkDJBlackhawksteipetesteipete
Timeline (top)
commented ×4cross-referenced ×4closed ×1

A local-loopback status/probe regression appears to begin in 2026.4.24 and continue in 2026.4.25.

On the affected machine, plain local status/probe commands can misreport the gateway as unreachable with Capability: unknown, while the gateway is actually alive and answering RPC successfully.

The strongest control checks are:

  • openclaw status --require-rpc succeeds
  • openclaw gateway status --require-rpc succeeds
  • direct low-level RPC status calls succeed
  • a 2026.4.23 client can successfully probe the same live newer gateway that 2026.4.24 / 2026.4.25 local status misreports

This suggests the regression is in the default local CLI status/probe path introduced in or before 2026.4.24, not that the gateway itself is dead.

Error Message

Plain local status path can fail / misreport, e.g. symptoms in this family:

  • Connectivity probe: failed
  • Capability: unknown
  • timeout against local loopback

Root Cause

Possibly adjacent but not the same root cause:

  • #72908 — .24 -> .25 mixed-version updater failure leaving old gateway running against replaced package files
  • #72146 — .24 LaunchAgent regression on macOS (looks similar at symptom level but appears platform/install-path specific)

Fix Action

Fixed

PR fix notes

PR #73724: fix(cli): avoid false local gateway unreachable on probe timeout

Description (problem / solution / changelog)

Summary

  • separate local gateway reachability from follow-up detail/read probe failures
  • add a bounded direct status-RPC fallback or degraded classification for local status/probe paths when the default probe times out or returns unknown capability but the gateway is otherwise RPC-capable
  • add regression coverage for the #73535 split: default local probe false-negative while --require-rpc or direct status RPC succeeds

Scope

This intentionally excludes unauthenticated loopback auth relaxation from #64400, which is routed to central security triage. The fix should stay in the ordinary status/probe classification and fallback path.

Credit

Fixes the non-security path tracked in #48360. Uses reproduction evidence from #62762 and #73535, with historical evidence from #51357 and #42019. Thanks @RacecarGuy, @justinschille, @DJBlackhawk, @tianyaqpzm, and @0xrsydn.

Validation

  • pnpm check:changed

ProjectClownfish replacement details:

  • Cluster: ghcrawl-156625-autonomous-smoke
  • Source PRs: none
  • Credit: Preserve reporter credit for #48360 by RacecarGuy, #62762 by justinschille, and #73535 by DJBlackhawk in the PR body.; Mention #51357 by tianyaqpzm and #42019 by 0xrsydn as earlier closed reports that supplied useful historical evidence.; Do not claim or implement #64400's unauthenticated loopback auth relaxation; say that security-shaped sub-scope is routed separately.
  • Validation: pnpm check:changed

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/cli/daemon-cli/probe.test.ts (modified, +83/-0)
  • src/cli/daemon-cli/probe.ts (modified, +25/-1)
  • src/commands/gateway-status/local-status-rpc-fallback.ts (added, +81/-0)
  • src/commands/gateway-status/probe-run.test.ts (added, +175/-0)
  • src/commands/gateway-status/probe-run.ts (modified, +32/-2)
  • src/commands/status.scan.shared.test.ts (modified, +45/-2)
  • src/commands/status.scan.shared.ts (modified, +17/-82)

PR #73171: Add bounded status gateway auth fallback

Description (problem / solution / changelog)

Summary

  • add a bounded fallback when resolving gateway auth for deep/status scans
  • preserve existing status behavior while avoiding hangs when auth lookup stalls
  • keep promised Discord decision digest artifact path present for tool-call audit output

Verification

  • git diff --check
  • focused Vitest status.scan.shared 6/6
  • tsc -p tsconfig.core.json --noEmit
  • oxfmt --check on touched status files
  • tool-call-audit node tests 11/11
  • vet no issues

Opened by Iris from Rex's verified fork branch for task 52563c3a after Martins/Iris internal unblock. No deploy/restart/merge performed.

Changed files

  • src/commands/status.scan.shared.test.ts (modified, +30/-0)
  • src/commands/status.scan.shared.ts (modified, +28/-3)
RAW_BUFFERClick to expand / collapse

[Bug]: local status/gateway status false-negative regression starts in 2026.4.24; --require-rpc and 2026.4.23 client still succeed

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

A local-loopback status/probe regression appears to begin in 2026.4.24 and continue in 2026.4.25.

On the affected machine, plain local status/probe commands can misreport the gateway as unreachable with Capability: unknown, while the gateway is actually alive and answering RPC successfully.

The strongest control checks are:

  • openclaw status --require-rpc succeeds
  • openclaw gateway status --require-rpc succeeds
  • direct low-level RPC status calls succeed
  • a 2026.4.23 client can successfully probe the same live newer gateway that 2026.4.24 / 2026.4.25 local status misreports

This suggests the regression is in the default local CLI status/probe path introduced in or before 2026.4.24, not that the gateway itself is dead.

Regression window

Known good:

  • 2026.4.23

Known bad:

  • 2026.4.24
  • 2026.4.25

User-observed onset was exactly at update 2026.4.24, with the same behavior continuing into .25 the next day.

Environment

  • OpenClaw CLI/runtime family: 2026.4.24 / 2026.4.25
  • Control comparison client: [email protected]
  • OS: Linux arm64 / Raspberry Pi-family system (Clockwork/uConsole context)
  • Gateway target: local loopback ws://127.0.0.1:18789
  • Gateway mode: local systemd user service
  • Auth: token / normal local authenticated setup

Observed behavior

Plain local status path can fail / misreport, e.g. symptoms in this family:

  • Connectivity probe: failed
  • Capability: unknown
  • timeout against local loopback

But at the same time:

  • openclaw gateway status --require-rpc works cleanly
  • openclaw status --require-rpc works cleanly
  • low-level callGateway({ method: "status" }) succeeds
  • low-level probeGateway(...) can succeed
  • the gateway process is running and reachable on loopback

High-confidence control evidence

  1. 2026.4.23 client against the same live gateway succeeds:

  2. Installed .24/.25 local default status path misreports / times out on the same host.

  3. --require-rpc succeeds on the affected install, pointing at the default top-level probe/status wrapper path rather than core gateway RPC failure.

Why this looks like a specific .24 regression

Public history appears to show a likely matching change sequence in .24:

  • perf(cli): trim gateway status startup work (43beceae)
  • fix(cli): preserve gateway status rpc probe semantics (2bf2fd6c)

That combination appears consistent with the observed split:

  • the default fast/light local probe path became less reliable
  • --require-rpc semantics were explicitly preserved/restored

Similar issues / possibly related upstream work

These look closely related:

  • #64400 — false restarts / false unreachable from hardcoded loopback timeout and probe-path behavior
  • #48360 — loopback probe false-negative while gateway is healthy
  • #73171 — bounded status gateway auth fallback
  • #68280 — fail fast on missing local probe auth

Possibly adjacent but not the same root cause:

  • #72908 — .24 -> .25 mixed-version updater failure leaving old gateway running against replaced package files
  • #72146 — .24 LaunchAgent regression on macOS (looks similar at symptom level but appears platform/install-path specific)

Additional notes about local noise we ruled out

There was also a separate corrupted runtime-deps/plugin-deps tree on this machine (including a missing chokidar dependency in a broken runtime-deps install). Repairing that corruption fixed a real secondary problem, but did not fix the core status / probe misreport.

That is why this report treats:

  1. the .24 local status/probe regression, and
  2. runtime-deps corruption / .25 startup-deps churn

as separate hypotheses unless evidence joins them.

Expected behavior

If the gateway is alive and RPC status succeeds, local status should not report the gateway as dead/unreachable or reduce capability to unknown without clearly separating probe-path uncertainty from actual gateway failure.

Actual behavior

Default local status/probe path can falsely report failure on .24/.25 even when RPC and older-client controls prove the gateway is healthy.

Suggested maintainer angle

Please inspect the .24 status/probe refactor path, especially the split between:

  • default local lightweight probe behavior
  • --require-rpc behavior

This looks like a regression in the default lightweight local path rather than a core gateway outage.

extent analysis

TL;DR

The most likely fix is to use the --require-rpc flag with the openclaw status and openclaw gateway status commands to ensure accurate reporting of the gateway's status.

Guidance

  • Verify that the gateway is indeed alive and responding to RPC requests by using the --require-rpc flag with the openclaw status and openclaw gateway status commands.
  • Check the OpenClaw CLI version and ensure that it is not affected by the known regression in versions 2026.4.24 and 2026.4.25.
  • If possible, try using an older version of the OpenClaw CLI, such as 2026.4.23, to see if the issue persists.
  • Inspect the default local lightweight probe behavior and the --require-rpc behavior to identify any potential issues or inconsistencies.

Example

openclaw status --require-rpc
openclaw gateway status --require-rpc

These commands can help verify that the gateway is alive and responding to RPC requests.

Notes

The issue appears to be specific to the default local status/probe path in OpenClaw CLI versions 2026.4.24 and 2026.4.25. Using the --require-rpc flag can provide a workaround, but a permanent fix may require changes to the OpenClaw CLI code.

Recommendation

Apply the workaround by using the --require-rpc flag with the openclaw status and openclaw gateway status commands, as this can provide accurate reporting of the gateway's status despite the regression in the default local status/probe path.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If the gateway is alive and RPC status succeeds, local status should not report the gateway as dead/unreachable or reduce capability to unknown without clearly separating probe-path uncertainty from actual gateway failure.

#authentication issue#prompt issue#agent setup#task chaining#parallel task

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: local status/gateway status false-negative regression starts in 2026.4.24; --require-rpc and 2026.4.23 client still succeed [2 pull requests, 4 comments, 3 participants]