openclaw - 💡(How to fix) Fix [Bug]: Telegram native approvals auto-enables on 2026.4.8 and spams "too many failed authentication attempts" in a retry loop [1 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#63381Fetched 2026-04-09 07:54:32
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Participants
Timeline (top)
labeled ×2

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).

Error Message

Control UI dashboard (Internal Server Error).

  • Fail gracefully with a clear error and stop retrying the Control UI dashboard with Internal Server Error.

Root Cause

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).

Fix Action

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.

RAW_BUFFERClick to expand / collapse

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

extent analysis

TL;DR

Explicitly disabling native approvals or configuring a valid gateway token for loopback authentication may resolve the issue.

Guidance

  • Verify that the OPENCLAW_GATEWAY_TOKEN environment variable is set correctly in the .env file.
  • Check the gateway authentication mode to ensure it is set to token and that the token is valid.
  • Consider setting channels.telegram.execApprovals.enabled to false to disable native approvals and prevent the retry loop.
  • Review the approvals.exec.targets configuration to ensure it is correctly set up for the Telegram channel.

Example

No code snippet is provided as the issue seems to be related to configuration rather than code.

Notes

The issue may be related to the inability of native approvals to locate a valid gateway token for loopback authentication, as indicated by tokenSource: "none" in the health endpoint. The fact that disabling native approvals resolves the issue suggests that the problem is specific to this feature.

Recommendation

Apply workaround: Explicitly disable native approvals by setting channels.telegram.execApprovals.enabled to false to prevent the retry loop and rate limiting issues. This will allow the gateway to function normally until a more permanent solution is found.

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

Native approvals should either:

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

Still need to ship something?

×6

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

Back to top recommendations

TRENDING