[brev]Telegram bridge: multiple sandboxes with same bot token cause 409 polling conflict — all bridges fail silently

[zNeill]

Description

[Description]
When multiple sandboxes (e.g. test222 and fff) are configured with Telegram bridge providers
that resolve to the same TELEGRAM_BOT_TOKEN from ~/.nemoclaw/credentials.json, both sandboxes
start independent long-polling loops against the Telegram Bot API. Telegram only allows one
getUpdates consumer per bot token, so each instance terminates the other's polling with
"409 Conflict: terminated by other getUpdates request". The result is that NO sandbox receives
messages — the bot appears completely unresponsive to the user in Telegram.

[Environment]
Device: Ubuntu (Brev cloud instance, massedcompute A100)
Node.js: v22.22.2
npm: 10.9.7
Docker: Docker version 28.0.4, build b8034c0
OpenShell CLI: 0.0.26
NemoClaw: v0.0.16
OpenClaw: 2026.4.2 (d74a122)

[Steps to Reproduce]

1. On a host with NemoClaw installed:
   nemoclaw onboard (create sandbox "test222" with Telegram channel enabled)
   nemoclaw onboard (create sandbox "fff" with Telegram channel enabled)
2. Both sandboxes resolve TELEGRAM_BOT_TOKEN from the same ~/.nemoclaw/credentials.json
3. Both sandboxes start Telegram bridge polling
4. Send a message to the bot in Telegram
5. Observe: no response from either sandbox

[Expected Result]

• Only the currently active/default sandbox's Telegram bridge should poll, OR
• NemoClaw should detect the conflict at onboard/start time and warn:
  "TELEGRAM_BOT_TOKEN is already in use by sandbox 'test222'. Only one sandbox
  can poll per bot token."
• At minimum, one sandbox should work reliably

[Actual Result]
Both sandboxes enter a conflict loop visible in /tmp/gateway.log:

[telegram] getUpdates conflict: Call to 'getUpdates' failed!
(409: Conflict: terminated by other getUpdates request;
make sure that only one bot instance is running); retrying in 30s.

This repeats indefinitely every ~30s on both sandboxes. No messages are delivered.
The user sees no error in the CLI — nemoclaw status shows the bridge as running.
The only way to diagnose is reading /tmp/gateway.log inside the sandbox.

[Root Cause Analysis]

• Each sandbox's nemoclaw-start.sh launches the OpenClaw gateway, which starts the
  Telegram bridge from the messaging channel config baked into the sandbox image.
• The bridge uses Telegram's long-polling mode (getUpdates), which is exclusive —
  Telegram enforces one consumer per bot token.
• NemoClaw does not check whether another sandbox is already polling with the same
  bot token before starting the bridge.
• The credential injection path (openshell provider → env resolution) means all
  sandboxes with a telegram-bridge provider resolve to the same host-level
  TELEGRAM_BOT_TOKEN in credentials.json.

Suggested fix:

• Option A: At nemoclaw onboard or nemoclaw start time, check if another
  registered sandbox already has a telegram-bridge provider. If so, warn the user
  and refuse to create a duplicate.
• Option B: Only start the Telegram bridge in the default sandbox (or the one
  most recently started), and skip it in others.
• Option C: Surface the 409 conflict error clearly in nemoclaw status output
  instead of silently showing "bridge running".

Bug Details

Field	Value
Priority	Unprioritized
Action	Dev - Open - To fix
Disposition	Open issue
Module	Machine Learning - NemoClaw
Keyword	NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL, NemoClaw_Inference, NemoClaw-SWQA-RelBlckr-Recommended

---

[NVB# 6084067]