Description

On Ubuntu 22.04 (Brev GCP, x86_64) with nemoclaw v0.0.52, after channels add telegram registers credentials in ~/.nemoclaw/sandboxes.json AND a subsequent rebuild --yes rolls the sandbox container, the in-sandbox Telegram bridge process never spawns. Symptoms:

• docker exec <sandbox> ps aux | grep -iE 'telegram|tgbot|bridge' returns empty (no bridge process).
• /sandbox/.openclaw/telegram/ directory exists but contains zero files (no bridge logs, no state).
• The sandbox does NOT poll the Telegram bot: a parallel curl https://api.telegram.org/bot<token>/getUpdates from another network returns {"ok":true,"result":[]} — NOT HTTP 409 Conflict, which would be the expected response if the sandbox were polling.
• Messages sent to the bot via sendMessage Bot API are accepted by Telegram ("ok":true, message_id:NNN) but the sandbox never receives or acts on them — no agent reply, no log entry in nemoclaw <name> logs, no inference call to the model.
• sandboxes.json shows "messagingChannels": ["telegram"] so the static config persists across rebuild, but the runtime bridge is absent.

Net effect: end-to-end messaging through Telegram is impossible on v0.0.52 on Brev, even with a fresh sandbox + a real working bot token + a real chat_id + a properly egress-permitted host (Brev has unrestricted egress to api.telegram.org, verified by direct getMe succeeding from the same shell).

DevTest cases affected (v0.0.52 folder 1179566):

• 639408 "Rebuild preserves presets E2E messaging" — cannot demonstrate preserved E2E because E2E never works.
• 639404 "Telegram 409 conflict handling" — cannot trigger 409 because the sandbox is not polling.

Earlier I observed the same on DGX Spark 110 / SP110 (Ubuntu 24.04 aarch64), but corp-network blocking of api.telegram.org masked the bridge-spawn gap. The Brev retest isolates it: with Telegram reachable, the bridge STILL does not spawn — confirming the issue is in the sandbox-side bridge launcher, not in network reachability.

Environment

Device:        Brev GCP instance (e2-standard-2, 2 vCPU / 16 GiB / 256 GiB)
OS:            Ubuntu 22.04.5 LTS
Architecture:  x86_64
Region:        GCP Mumbai
Node.js:       v22.22.3
npm:           10.9.8
Docker:        Docker version 29.5.2
OpenShell CLI: 0.0.44 (docker)
NemoClaw:      v0.0.52
OpenClaw:      2026.5.22 (a374c3a)
Telegram bot:  real bot token verified via curl getMe (bot id 8771941195, username nemotest2_bot)
Telegram chat: 8321789948 (private chat)
Egress to api.telegram.org: verified working from this Brev host

Steps to Reproduce

1. On Brev (or any host with public egress to api.telegram.org), install nemoclaw v0.0.52:

   NEMOCLAW_INSTALL_TAG=v0.0.52 NEMOCLAW_NON_INTERACTIVE=1 \
   NVIDIA_API_KEY=<key> NEMOCLAW_PROVIDER_KEY=<key> NEMOCLAW_PROVIDER=build \
   bash -c 'curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash'

2. Verify Telegram reachability:

   curl 'https://api.telegram.org/bot<token>/getMe'
   # → {"ok":true, "result":{...}}

3. Onboard a fresh sandbox:

   nemoclaw onboard --non-interactive --yes --no-gpu --name tg-test --fresh

4. Add telegram channel with real bot credentials:

   TELEGRAM_BOT_TOKEN=<real-token> \
   TELEGRAM_CHAT_ID=<real-chat-id> \
   TELEGRAM_AUTHORIZED_CHAT_IDS=<same-chat-id> \
   nemoclaw tg-test channels add telegram

5. Trigger rebuild to apply (recommended UX prompt says rebuild required):

   nemoclaw tg-test rebuild --yes

6. Wait 30s for sandbox container health: starting → healthy. Then:

   docker exec $(docker ps --format '{{.Names}}' | grep openshell-tg-test) ps aux | grep -iE 'telegram|tgbot|bridge'
   # Expected: at least one process. Observed: zero processes.
   
   docker exec ... ls -la /sandbox/.openclaw/telegram/
   # Expected: bridge logs / runtime files. Observed: empty directory.

7. Send a message to the bot from the same host:

   curl -X POST 'https://api.telegram.org/bot<token>/sendMessage' \
     -d 'chat_id=<id>' --data-urlencode 'text=hello bot please reply'
   # → Telegram accepts (200, message_id=N)

8. Wait 120s. Check nemoclaw logs for any sign of incoming message:

   nemoclaw tg-test logs --tail 200 | grep -iE 'telegram|update_id|message_id|chat'
   # Expected: entries from a working bridge. Observed: zero entries.

9. Confirm sandbox is NOT polling Telegram (would otherwise return 409):

   curl 'https://api.telegram.org/bot<token>/getUpdates?timeout=2&limit=5&offset=-5'
   # Expected: HTTP 409 Conflict (if sandbox is polling) OR a list of unconsumed updates.
   # Observed: {"ok":true,"result":[]} — no conflict, no updates → no poller exists anywhere.

Expected Result

After step 5 (rebuild applies the telegram channel registration):

• A telegram bridge process should be running inside the sandbox container, owned by the sandbox user, polling the Telegram bot via getUpdates long-poll.
• /sandbox/.openclaw/telegram/ should contain a runtime log / state file.
• Messages sent to the bot in step 7 should be picked up within the long-poll window (typically <30s), processed by the agent, and replied back to the chat via sendMessage Bot API.
• A parallel external getUpdates call (step 9) should return HTTP 409 Conflict because the sandbox is exclusively polling.
• nemoclaw logs should show [telegram] received update {update_id}: ... or equivalent entries.

Actual Result

Step 6: no telegram process visible in sandbox process list. Directory /sandbox/.openclaw/telegram/ is empty (only `.` and `..`).
Step 7: sendMessage returns {"ok":true,"result":{"message_id":743,...}} — Telegram accepts, but no downstream effect.
Step 8: nemoclaw logs contain only inference-proxy entries (e.g. openshell_router routing to integrate.api.nvidia.com), zero telegram-related entries.
Step 9: getUpdates returns {"ok":true,"result":[]} — no 409 conflict, confirming no poller is running anywhere.

End-to-end conclusion: the channels add wrote ["telegram"] to sandboxes.json and "registered" the bridge with the OpenShell gateway (per the success message during channels add), but the actual in-sandbox bridge launcher never spawned a poller process, even after explicit rebuild. The user's intent (enable Telegram messaging on this sandbox) is silently unfulfilled.

Logs

Channels add output (succeeded per stdout):

$ TELEGRAM_BOT_TOKEN=... nemoclaw tg-test channels add telegram
  ✓ Registered telegram bridge with the OpenShell gateway.
  Widening sandbox egress — adding: api.telegram.org

Rebuild output: container rotates UUID (verified via docker ps before/after) — old 4ef... replaced by new 4740a26d-d118-4593-acc7-0d688709c42a. So rebuild DID run the sandbox container.

Container health post-rebuild:

$ docker ps --format '{{.Names}}\t{{.Status}}'
openshell-tg-test-4740a26d-d118-4593-acc7-0d688709c42a   Up 31 seconds (health: starting)
nemoclaw-openshell-gateway                                Up 8 minutes

Process list inside sandbox (telegram-related grep):

$ docker exec openshell-tg-test-... ps aux | grep -iE 'telegram|tgbot|bridge'
(no output — empty)

Telegram dir inside sandbox:

$ docker exec ... ls -la /sandbox/.openclaw/telegram/
total 12
drwxrws--- 1 sandbox sandbox 4096 May 27 00:49 .
drwxrws--- 1 sandbox sandbox 4096 May 27 11:21 ..
(zero files inside)

nemoclaw logs telegram-filtered (over 200 most recent lines):

$ nemoclaw tg-test logs --tail 200 | grep -iE 'telegram|update_id|message_id|chat'
[1779880905.350] [sandbox] [INFO ] [openshell_router] routing proxy inference request (streaming) endpoint=https://integrate.api.nvidia.com/v1 method=GET path=/v1/models protocols=openai_chat_completions,openai_completions,openai_responses,model_discovery
(only the unrelated inference proxy line; no telegram entries)

External getUpdates probe (confirming no poller exists):

$ curl 'https://api.telegram.org/bot<token>/getUpdates?timeout=2&limit=5&offset=-5'
{"ok":true,"result":[]}
(expected 409 if sandbox were polling — observed empty result instead)

NVB#6229872