Telegram plugin not polling on Windows — auto-enabled but never starts

[minor aspen]

Telegram plugin auto-enabled but never starts polling on Windows.

Env: Windows 11, AutoClaw v1.1.1.91 (OpenClaw 2026.3.11), Node.js v22.22.0, gateway port 18789 local.

Config: enabled:true, dmPolicy:pairing, botToken set at both root and account level, dmPolicy:open, allowFrom:[*], groupPolicy:open.

Verified: getMe returns correct bot info. getWebhookInfo: no webhook, pending_update_count:0.

Symptoms:

• Log shows "Telegram configured, enabled automatically" then zero activity
• No polling started, no getMe, no errors after that
• Health monitor starts but no Telegram connect event fires
• Later: "telegram plugin not loaded after in-process restart"

Windows SIGUSR1 bug: config.patch triggers restart -> GatewayLockError on ws://127.0.0.1:18789 (old process holds port). Only taskkill /f /im AutoClaw.exe + relaunch works. But Telegram still won't poll after clean restart.

Tried: multiple bot tokens, root vs account-level botToken, all dmPolicy values, config doctor, clean restarts. Plugin is bundled in gateway-bundle.mjs (not in extensions folder).

Questions:

1. Is Telegram polling broken on Windows in this build?
2. How to enable verbose logging for Telegram plugin?
3. Is the SIGUSR1 port-lock a known Windows issue?
4. Correct botToken placement: root, account, or both?

[humble crane]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[sonic mica]

I checked the current docs/code. This does not look like a normal token/policy config issue.

A healthy Telegram startup path should do roughly: resolve account/token → startup getMe probe → log [default] starting provider (@botname) → clear webhook → start grammY long polling. If you only get Telegram configured, enabled automatically and then no getMe / no [default] starting provider, the channel runtime is probably never being started/loaded.

Answers:

1. Polling itself is not supposed to be broken, but 2026.3.11 is old relative to several Telegram + Windows fixes I found after it, including Telegram polling teardown/stall handling and Windows plugin-loader/restart fixes. I’d treat this as a likely build/runtime bug in that AutoClaw/OpenClaw build, not a BotFather/token problem.

2. Verbose logging:

$env:OPENCLAW_LOG_LEVEL="debug"
$env:OPENCLAW_DEBUG_TELEGRAM_ACCOUNTS="1"
$env:OPENCLAW_DEBUG_TELEGRAM_INGRESS="1"
$env:OPENCLAW_DIAGNOSTICS="telegram.http"
openclaw gateway

Or persist the broad log level in config:

logging: { level: "debug" }

Docs: https://docs.openclaw.ai/logging and https://docs.openclaw.ai/diagnostics/flags

3. The Windows restart/port-lock part sounds real. The code uses SIGUSR1-style in-process restart paths, and there have been multiple Windows restart/lock/race fixes after older builds. For this repro, avoid judging Telegram after config.patch restart. Do a hard AutoClaw exit/kill + relaunch, exactly like you did.

4. Token placement: for a single bot, use one of these, preferably root-level:

channels: {
  telegram: {
    enabled: true,
    botToken: "123:abc",
    dmPolicy: "open",
    allowFrom: ["*"],
    groupPolicy: "open",

    groups: { "*": { requireMention: false } },
  },
}

Use channels.telegram.accounts.<id>.botToken only for multi-bot setups. Don’t duplicate the same token across multiple account entries; current code explicitly treats duplicate bot tokens as an error. Root + accounts.default is unnecessary even if it may not always trip the duplicate guard.

Recommended next step: upgrade AutoClaw/OpenClaw if possible and retry with the simplified single-token config above. If it still logs auto-enabled but never logs [default] starting provider, please file a GitHub issue with the redacted debug log + openclaw status --all: https://github.com/openclaw/openclaw/issues

[minor aspen]

Update: Enabled debug logging (OPENCLAW_LOG_LEVEL=debug, OPENCLAW_DEBUG_TELEGRAM_ACCOUNTS=1, OPENCLAW_DEBUG_TELEGRAM_INGRESS=1). Debug logs confirm: after "Telegram configured, enabled automatically", there is zero Telegram-related output — no getMe probe, no [default] starting provider, no errors. The plugin is detected but the channel runtime never initializes it. No telegram.http diagnostics file was created. Confirmed this is a runtime bug, not a config issue.