Telegram polling stalls indefinitely with Network request for 'getUpdates' failed! despite channels.telegram.proxy configured (v2026.4.24, macOS)

Summary

On a 国内 (China-mainland) network where api.telegram.org requires HTTP proxy, telegram polling enters a stall loop with Network request for 'getUpdates' failed! even when channels.telegram.proxy is set in ~/.openclaw/openclaw.json. The bundled HTTP proxy (Clash Verge) at http://127.0.0.1:7890 is verified to reach api.telegram.org via plain curl. Workaround: inject setGlobalDispatcher(new EnvHttpProxyAgent()) at dist/index.js boot — but this should be wired natively by the gateway when proxy env vars or channels.telegram.proxy are present.

Environment

• macOS 25.4.0 (Apple Silicon M3, 16GB)
• node v24.14.1 (fnm)
• openclaw v2026.4.24 (npm latest), launchd-managed
• Clash Verge HTTP proxy http://127.0.0.1:7890 (TCP only, no TUN)
• All standard proxy env vars set in ~/Library/LaunchAgents/ai.openclaw.gateway.plist EnvironmentVariables:
  • HTTP_PROXY / HTTPS_PROXY / http_proxy / https_proxy / all_proxy / ALL_PROXY / NO_PROXY / no_proxy
• macOS system proxy ON (HTTPEnable=1, HTTPSEnable=1, port 7890)

Repro

~/.openclaw/openclaw.json:

{
  "channels": {
    "telegram": {
      "enabled": true,
      "botToken": "<your bot token>",
      "proxy": "http://127.0.0.1:7890",
      "dmPolicy": "allowlist",
      "allowFrom": ["tg:<your chat id>"]
    }
  }
}

Then: launchctl kickstart -k gui/$UID/ai.openclaw.gateway

Expected

Telegram polling reaches api.telegram.org through 127.0.0.1:7890, getUpdates succeeds.

Actual

~/.openclaw/logs/gateway.err.log:

[telegram] Polling stall detected (active getUpdates stuck for 543.01s); forcing restart.
[telegram] [diag] polling cycle finished reason=polling stall detected ...
  outcome=error ... error=Network request for 'getUpdates' failed!
[telegram] polling runner stopped (polling stall detected); restarting in 2.41s.
[telegram] [diag] closing stale transport before rebuild
[telegram] [diag] rebuilding transport for next polling cycle

Repeats indefinitely. Each polling cycle consumes 136s–543s before stall detection. CPU spikes during retry.

Verification proxy itself works

TOKEN=$(jq -r .channels.telegram.botToken ~/.openclaw/openclaw.json)
curl -s -m 10 -x http://127.0.0.1:7890 "https://api.telegram.org/bot${TOKEN}/getMe" | jq .ok
# → true
curl -s -m 10 -x http://127.0.0.1:7890 "https://api.telegram.org/bot${TOKEN}/getUpdates?timeout=5"
# → {"ok":true,"result":[]}

Proxy reaches telegram api in ~1s. The issue is openclaw not threading the proxy into the telegram polling fetcher.

Code paths inspected (dist v2026.4.24)

• dist/extensions/telegram/probe-ChPXZhx2.js:302 — appears to construct proxyFetch from account.config.proxy:

  const proxyFetch = opts.proxyFetch ?? (account.config.proxy ? makeProxyFetch(account.config.proxy) : void 0);

• dist/extensions/telegram/account-config-Cifs-fXF.js:8 — mergeTelegramAccountConfig should expose proxy via ...base spread of cfg.channels.telegram.
• dist/extensions/telegram/monitor-polling.runtime-cvefT1B7.js:280-286 — passes proxyFetch: this.opts.proxyFetch into createTelegramBot.
• dist/extensions/telegram/bot-gUR32RLX.js:5086 — resolveTelegramTransport(opts.proxyFetch, { network: telegramCfg.network }).

The static path looks correct. Either (a) account.config.proxy resolves to undefined at runtime in some merge edge case, or (b) proxyFetch is constructed but the resulting dispatcher isn't applied to the actual grammy transport, or (c) some retry/fallback path bypasses it. I didn't trace down to grammy Bot construction details.

Workaround that works (hotpatch)

Patching dist/index.js to install a global undici dispatcher at boot resolves the stall:

 import process from "node:process";
 import { fileURLToPath } from "node:url";
+try {
+  const { setGlobalDispatcher, EnvHttpProxyAgent } = await import("undici");
+  if (process.env.HTTP_PROXY || process.env.HTTPS_PROXY || process.env.http_proxy || process.env.https_proxy) {
+    setGlobalDispatcher(new EnvHttpProxyAgent());
+  }
+} catch (_e) { /* undici unavailable */ }
 //#region src/index.ts

After this patch + launchctl kickstart -k:

• Polling stall errors gone
• getUpdates reaches api.telegram.org and returns business responses (incl. 409 Conflict: terminated by other getUpdates request if multiple bot instances exist — separate issue)
• Telegram messages flow normally

This is a dist/ patch and gets overwritten on npm i -g openclaw@latest. Suggested upstream fixes:

Option A — global dispatcher fallback at gateway boot

Install EnvHttpProxyAgent as setGlobalDispatcher at the entry when standard proxy env vars are present, similar to the patch above. This handles the broad case of "user set HTTP_PROXY but a transitive lib doesn't honor it".

Option B — explicit dispatcher injection into grammy bot

Confirm at runtime that account.config.proxy from cfg.channels.telegram.proxy actually reaches the grammy Bot instance's HTTP client, and add a runtime log line at startup like [telegram] account=<id> proxy=<url|none> for visibility (currently proxy: … only appears in the static config dump, not in the polling start log).

Option C — document explicitly

If channels.telegram.proxy is intentionally probe-only (not polling), document that explicitly and require either TUN-mode proxy or setGlobalDispatcher as the supported approach for restricted networks.

Other observations during repro

• [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable) — appears after telegram-induced lane stalls; suggests a single failed lane (session:agent:main:main:heartbeat) cascades to lock cron service. Even after the underlying network recovers, gateway never self-heals; only launchctl kickstart -k clears the state. Worth a separate auto-recovery issue.
• [plugins] bonjour: watchdog detected non-announced service; attempting re-advertise — recurring every ~21 minutes regardless of telegram health.

Happy to test a fix on this machine.