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]
- On a host with NemoClaw installed:
nemoclaw onboard (create sandbox "test222" with Telegram channel enabled)
nemoclaw onboard (create sandbox "fff" with Telegram channel enabled)
- Both sandboxes resolve TELEGRAM_BOT_TOKEN from the same ~/.nemoclaw/credentials.json
- Both sandboxes start Telegram bridge polling
- Send a message to the bot in Telegram
- 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]
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]
nemoclaw onboard (create sandbox "test222" with Telegram channel enabled)
nemoclaw onboard (create sandbox "fff" with Telegram channel enabled)
[Expected Result]
"TELEGRAM_BOT_TOKEN is already in use by sandbox 'test222'. Only one sandbox
can poll per bot token."
[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 statusshows the bridge as running.The only way to diagnose is reading /tmp/gateway.log inside the sandbox.
[Root Cause Analysis]
Telegram bridge from the messaging channel config baked into the sandbox image.
Telegram enforces one consumer per bot token.
bot token before starting the bridge.
sandboxes with a telegram-bridge provider resolve to the same host-level
TELEGRAM_BOT_TOKEN in credentials.json.
Suggested fix:
nemoclaw onboardornemoclaw starttime, check if anotherregistered sandbox already has a telegram-bridge provider. If so, warn the user
and refuse to create a duplicate.
most recently started), and skip it in others.
nemoclaw statusoutputinstead of silently showing "bridge running".
Bug Details
[NVB# 6084067]