Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to 2026.4.8, the Telegram native approvals subsystem
auto-enables (as documented in FAQ for 4.8) but immediately fails
authentication in a tight retry loop, spamming the log every ~1 second
and causing the gateway to become rate-limited, which also breaks the
Control UI dashboard (Internal Server Error).

Steps to reproduce

1. Have a working Telegram channel configured with allowFrom set to
   a numeric user ID
2. Do NOT set channels.telegram.execApprovals.enabled (leave unset,
   so it defaults to "auto")
3. Upgrade to 2026.4.8
4. Start the gateway

Expected behavior

Native approvals should either:

• Successfully obtain a loopback token and connect, OR
• Fail gracefully with a clear error and stop retrying

Actual behavior

Gateway log spams the following every ~1 second continuously:

[telegram] failed to start native approval handler: 
GatewayClientRequestError: unauthorized: too many failed 
authentication attempts (retry later)

[ws] unauthorized conn=... client=Telegram Native Approvals (default) 
backend v2026.4.8 reason=rate_limited

The health endpoint for native approvals shows:
"running": false
"tokenSource": "none"

The retry loop causes the gateway's rate limiter to trigger, which blocks
the Control UI dashboard with Internal Server Error.

OpenClaw version

2026.4.8

Operating system

Linux arm64 (Raspberry Pi 3, Ubuntu) + Windows WSL2

Install method

npm global

Model

na

Provider / routing chain

na

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Workaround

Explicitly disabling native approvals stops the retry loop:

openclaw config set channels.telegram.execApprovals.enabled false

The config hot-reloads immediately without gateway restart.

Config (redacted)

"channels": {
  "telegram": {
    "enabled": true,
    "botToken": "<redacted>",
    "dmPolicy": "allowlist",
    "allowFrom": [<numeric_user_id>],
    "streaming": { "mode": "partial" }
  }
},
"approvals": {
  "exec": {
    "enabled": true,
    "mode": "targets",
    "targets": [{ "channel": "telegram", "to": "<numeric_user_id>" }]
  }
}

Notes

• The tokenSource: "none" in the health endpoint suggests native
  approvals cannot locate a valid gateway token for loopback auth
• Gateway auth mode is token with OPENCLAW_GATEWAY_TOKEN in .env
• Reproduced on both Pi3 (arm64) and Windows WSL2 after upgrading to 4.8
• Same issue occurs regardless of whether channels.telegram.execApprovals
  is explicitly set or left unset