Bug type

Behavior bug

Summary

openclaw health --json reports a configured Telegram channel as not running with tokenSource: "none" even though openclaw channels status --json, openclaw channels status --probe, and live Telegram traffic all show the same account running normally from config.

Steps to reproduce

1. Configure Telegram with a plain channels.telegram.botToken in ~/.openclaw/openclaw.json5.
2. Start or restart the local gateway and verify Telegram traffic is working.
3. Run:

openclaw config validate
openclaw channels status --probe
openclaw health --json | jq '{telegram:(.channels.telegram // {})}'
openclaw channels status --json | jq '{telegram:(.channels.telegram // {})}'

4. Compare the two JSON payloads for the same Telegram account.

Expected behavior

openclaw health --json should reflect the live Telegram runtime state from the running gateway, or at minimum agree with openclaw channels status --json on running, lastStartAt, mode, and tokenSource.

Actual behavior

On my machine, openclaw health --json reports Telegram as:

{
  "configured": true,
  "running": false,
  "lastStartAt": null,
  "lastStopAt": null,
  "lastError": null,
  "tokenSource": "none",
  "mode": null
}

At the same time, openclaw channels status --json reports:

{
  "configured": true,
  "running": true,
  "lastStartAt": 1773508368414,
  "lastStopAt": null,
  "lastError": null,
  "tokenSource": "config",
  "lastProbeAt": null,
  "mode": "polling"
}

Higher-level checks also say Telegram is healthy:

$ openclaw channels status --probe
Checking channel status (probe)…
Gateway reachable.
- Telegram default: enabled, configured, running, in:56m ago, mode:polling, bot:@agentctlbot, token:config, works

$ openclaw doctor | rg 'Telegram:'
65:Telegram: ok (@agentctlbot) (974ms)

openclaw config validate also passes for this config.

OpenClaw version

2026.3.13

Operating system

macOS 26.3.1

Install method

npm global (openclaw@2026.3.13)

Model

Not model-specific. Local default agent model is anthropic/claude-opus-4-6, but this repro is in the CLI/gateway diagnostics path and does not depend on model execution.

Provider / routing chain

Local OpenClaw gateway only. No external model/provider call is needed to reproduce the mismatch.

Config file / key location

~/.openclaw/openclaw.json5; channels.telegram.botToken

Additional provider/model setup details

Single local gateway, Telegram polling mode, default Telegram account.

Logs, screenshots, and evidence

$ openclaw health --json | jq '{runtimeVersion, telegram:(.channels.telegram // {})}'
{
  "runtimeVersion": null,
  "telegram": {
    "configured": true,
    "running": false,
    "lastStartAt": null,
    "lastStopAt": null,
    "lastError": null,
    "tokenSource": "none",
    "probe": {
      "ok": true,
      "status": null,
      "error": null,
      "elapsedMs": 1067
    },
    "lastProbeAt": 1773512449024,
    "mode": null,
    "accountId": "default"
  }
}

$ openclaw channels status --json | jq '{ts, telegram:(.channels.telegram // {})}'
{
  "ts": 1773512475439,
  "telegram": {
    "configured": true,
    "running": true,
    "lastStartAt": 1773508368414,
    "lastStopAt": null,
    "lastError": null,
    "tokenSource": "config",
    "lastProbeAt": null,
    "mode": "polling"
  }
}

Impact and severity

Affected: operators relying on openclaw health --json for Telegram diagnostics

Severity: medium; Telegram itself is working, but the health output is misleading

Frequency: 100% repro on this machine

Consequence: false incident signals and wasted debugging time because health suggests Telegram is stopped or misconfigured when it is actually running and receiving traffic

Additional information

This looks adjacent to the current scope-limited diagnostics work, but not the same bug. The closest PR I found was #31307, which only patched the dashboard debug view by overlaying channels.status onto health output; it did not change the underlying CLI/gateway health snapshot path.