Skip to content

Windows: openclaw status / status --json hangs in 2026.5.18 while status --all succeeds #84001

Description

@euroboy18

Summary

After upgrading to OpenClaw 2026.5.18, openclaw status and openclaw status --json --timeout 3000 hang on Windows. However, openclaw status --all --timeout 3000 completes successfully.

This looks like the default/json status path hangs during data collection/runtime snapshot, while the --all diagnostic path handles the same environment correctly.

Environment

  • OS: Windows 10.0.26300 x64
  • Node.js: v24.14.0
  • OpenClaw: 2026.5.18 (50a2481)
  • Gateway bind: lan / 0.0.0.0
  • Gateway port: 18789

Reproduction

openclaw gateway health
openclaw gateway status
openclaw status --timeout 3000
openclaw status --json --timeout 3000
openclaw status --all --timeout 3000

Actual behavior

openclaw gateway health succeeds:

Gateway Health
OK
Telegram: configured
WhatsApp: linked
QQ Bot: configured
Feishu: configured

openclaw gateway status succeeds and reports:

Gateway version: 2026.5.18
Runtime: running
Connectivity probe: ok
Capability: admin-capable
Service: Scheduled Task (registered)

But these commands hang until externally timed out:

openclaw status --timeout 3000
openclaw status --json --timeout 3000
openclaw status --json --all --timeout 3000

This command does not hang:

openclaw status --all --timeout 3000

It prints the full diagnostic report successfully, including gateway reachability, channels, agents, and service information.

Notes

Before reinstalling the gateway service, the gateway was in a half-responsive state: port 18789 was listening, but gateway health timed out. Reinstalling and restarting the gateway fixed that part:

openclaw gateway install --force --port 18789
openclaw gateway start

After that, gateway health and gateway status were healthy, but default/json status still hung.

On this machine, direct schtasks queries can return:

ERROR: The system cannot find the path specified.

So one possibility is that the default/json status path hangs while collecting runtime/service summary on Windows, whereas the --all diagnostic path degrades gracefully.

Expected behavior

openclaw status and openclaw status --json --timeout 3000 should return or fail with a bounded timeout, similar to openclaw status --all --timeout 3000.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:crash-loopCrash, hang, restart loop, or process-level availability failure.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.staleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions