Description

On nemohermes v0.0.48, the Hermes Telegram gateway internally spawns two concurrent async getUpdates polling coroutines. They race each other on the same bot token: one coroutine wins and should process messages, while the other gets a 409 Conflict response every ~25 seconds indefinitely. Because the loser coroutine continuously restarts its polling loop, the winner is repeatedly interrupted — sendMessage is never called and the Telegram bridge is completely non-functional for the lifetime of the sandbox. On v0.0.49 the same dual-coroutine pattern exists but the conflict resolves itself after one occurrence at startup (~15s window), leaving a gap where early messages may be missed.

Environment

Device:        Brev cloud (GCP g2-standard-4, NVIDIA L4 GPU)
OS:            Ubuntu 22.04.5 LTS (x86_64)
Architecture:  x86_64
Node.js:       v22.22.3
npm:           10.9.8
Docker:        Docker Engine 29.5.0
OpenShell CLI: 0.0.39
NemoClaw:      nemohermes v0.0.48 (primary repro) / v0.0.49 (partial)
Hermes Agent:  v2026.4.23
OpenClaw:      N/A (NemoHermes sandbox)
Ollama:        0.24.0 / model: qwen2.5:0.5b

Steps to Reproduce

1. On a clean Ubuntu 22.04 machine with Docker and Ollama installed:
   export NEMOCLAW_AGENT=hermes
   export NEMOCLAW_INSTALL_TAG=v0.0.48
   curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash
2. During onboard wizard: select Local Ollama, enable Telegram channel,
   enter a valid Telegram bot token and user ID.
3. Complete onboarding (policy presets → confirm).
4. Watch /sandbox/.hermes/logs/agent.log or run:
   nemohermes hermes logs 2>&1 | grep -i telegram
5. From Telegram app, send a DM to the configured bot.

Expected Result

• agent.log shows "[Telegram] Connected to Telegram (polling mode)" once at startup.
• Incoming DM is logged as "inbound message" and bot replies within 30s.
• No polling conflict warnings appear.

Actual Result

v0.0.48: From sandbox startup, the following warning repeats every ~25 seconds indefinitely:

WARNING gateway.platforms.telegram: [Telegram] Telegram polling conflict (1/3),
will retry in 10s. Error: Conflict: terminated by other getUpdates request;
make sure that only one bot instance is running

Network policy logs show only getUpdates and deleteWebhook calls — zero sendMessage
calls — for the entire sandbox lifetime. Bot never responds to any messages.

v0.0.49: One occurrence of the conflict at startup (~09:37:07), resolves after
~15s ("Telegram polling resumed after conflict retry 1" at ~09:37:22). After
recovery, DM messages are processed normally. However, messages arriving during
the ~15s conflict window are silently missed.

Only ONE sandbox was running; the conflict is internal to the Hermes gateway process
(not caused by multiple sandboxes sharing the same token — see related fixed bug
NVBug #6084067 which had a different root cause).

Logs

v0.0.48 agent.log (conflict repeating, no sendMessage ever):
  WARNING gateway.platforms.telegram: [Telegram] Telegram polling conflict (1/3), will retry in 10s. Error: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running
  [... repeats every ~25s for entire sandbox lifetime ...]

v0.0.48 network policy log (no sendMessage):
  HTTP:POST ALLOWED POST http://api.telegram.org:443/bot[CREDENTIAL]/getUpdates
  HTTP:POST ALLOWED POST http://api.telegram.org:443/bot[CREDENTIAL]/deleteWebhook
  HTTP:POST ALLOWED POST http://api.telegram.org:443/bot[CREDENTIAL]/getUpdates
  [... only getUpdates and deleteWebhook, zero sendMessage ...]

v0.0.49 agent.log (one transient conflict at startup, then recovers):
  2026-05-22 09:37:07,653 WARNING gateway.platforms.telegram: [Telegram] Telegram polling conflict (1/3), will retry in 10s. Error: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running
  2026-05-22 09:37:22,672 INFO gateway.platforms.telegram: [Telegram] Telegram polling resumed after conflict retry 1
  [... subsequent inbound messages processed normally ...]

Related (different root cause, already fixed): NVBug #6084067 — multiple sandboxes
sharing same bot token. This bug is a distinct internal dual-coroutine issue.

NVB#6205882