Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Bug: WhatsApp channel health JSON reports running=false/connected=false while status --deep shows OK/LINKED [1 comments, 2 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#71974•Fetched 2026-04-27 05:36:41
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
helgekrause007helgekrause007
Participants
clawsweeper[bot]clawsweeper[bot]helgekrause007helgekrause007
Timeline (top)
closed ×1commented ×1

openclaw health --json reports the WhatsApp channel as:

  • statusState: linked
  • running: false
  • connected: false
  • lastError: null

At the same time, openclaw status --deep consistently reports the same channel as:

  • WhatsApp: ON / OK
  • Health: LINKED
  • fresh auth age / linked state

This produced a false operational signal during a system health check. There was no verified auth/link failure and no restart was warranted.

Root Cause

This creates an operator-facing contradiction:

  • machine-readable health JSON suggests channel inactivity / disconnection
  • human-readable deep status suggests the channel is healthy and linked

That can trigger unnecessary restart decisions or false incident escalation.

Code Example

{
  "configured": true,
  "statusState": "linked",
  "linked": true,
  "running": false,
  "connected": false,
  "lastConnectedAt": null,
  "lastDisconnect": null,
  "lastError": null
}
RAW_BUFFERClick to expand / collapse

Summary

openclaw health --json reports the WhatsApp channel as:

  • statusState: linked
  • running: false
  • connected: false
  • lastError: null

At the same time, openclaw status --deep consistently reports the same channel as:

  • WhatsApp: ON / OK
  • Health: LINKED
  • fresh auth age / linked state

This produced a false operational signal during a system health check. There was no verified auth/link failure and no restart was warranted.

Observed behavior

openclaw health --json

Repeatedly returned WhatsApp channel fields equivalent to:

{
  "configured": true,
  "statusState": "linked",
  "linked": true,
  "running": false,
  "connected": false,
  "lastConnectedAt": null,
  "lastDisconnect": null,
  "lastError": null
}

openclaw status --deep

At the same time reported:

  • Channel table: WhatsApp | ON | OK | linked
  • Health table: WhatsApp | LINKED | linked
  • auth age updated normally

Why this matters

This creates an operator-facing contradiction:

  • machine-readable health JSON suggests channel inactivity / disconnection
  • human-readable deep status suggests the channel is healthy and linked

That can trigger unnecessary restart decisions or false incident escalation.

Expected behavior

One of the following should be true:

  1. health --json and status --deep use the same underlying channel-state semantics, or
  2. the JSON fields are documented clearly enough that running=false / connected=false are not misread as a live channel failure when statusState=linked and status --deep is healthy.

Reproduction

Stable repro on macOS host with linked WhatsApp account:

  1. Run openclaw health --json
  2. Inspect channels.whatsapp.running and channels.whatsapp.connected
  3. Run openclaw status --deep
  4. Compare WhatsApp channel state

Observed repeatedly:

  • health --json: running=false, connected=false
  • status --deep: OK / LINKED

Environment

  • OpenClaw CLI/package version observed locally: 2026.4.21
  • macOS 26.4 (arm64)
  • Gateway reachable locally
  • WhatsApp account linked, no lastError

Operational outcome

  • No real incident
  • No restart performed
  • Classified as likely product/status bug or semantic mismatch in health reporting

extent analysis

TL;DR

The discrepancy between openclaw health --json and openclaw status --deep outputs for the WhatsApp channel status may be due to inconsistent channel-state semantics, requiring clarification or documentation of the JSON fields.

Guidance

  • Verify the documentation for openclaw health --json to understand the meaning of running and connected fields when statusState is linked.
  • Compare the implementation of openclaw health --json and openclaw status --deep to identify potential semantic mismatches in channel-state reporting.
  • Check if there are any open issues or pull requests related to channel-state reporting inconsistencies in the OpenClaw project.
  • Consider filing an issue or requesting clarification on the OpenClaw project to resolve the discrepancy and prevent future false incident escalations.

Notes

The issue seems to be related to a potential bug or semantic mismatch in the OpenClaw project, and resolving it may require changes to the project's code or documentation.

Recommendation

Apply workaround: Request clarification on the OpenClaw project to resolve the discrepancy and prevent future false incident escalations, as the current behavior may lead to unnecessary restart decisions or false incident escalations.

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

One of the following should be true:

  1. health --json and status --deep use the same underlying channel-state semantics, or
  2. the JSON fields are documented clearly enough that running=false / connected=false are not misread as a live channel failure when statusState=linked and status --deep is healthy.
#embedding generation#cache error#pipeline error#runtime error#dependency conflict

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 - 💡(How to fix) Fix Bug: WhatsApp channel health JSON reports running=false/connected=false while status --deep shows OK/LINKED [1 comments, 2 participants]