Description

On a fresh NemoClaw v0.0.54 / OpenClaw 2026.5.22 sandbox (tg-test) on a Ubuntu 22.04 host, the Telegram channel appears to configure and start successfully, but end-to-end chat with the sandbox agent does not work as expected. After adding the Telegram channel, rebuilding the sandbox, and verifying that the Telegram provider starts and polls getUpdates against api.telegram.org under policy:telegram_bot, messages sent to the bot are accepted by Telegram (sendMessage returns ok:true with a valid message_id and correct chat id). However, no replies ever appear in the Telegram client from the sandbox agent, even after waiting 60–120 seconds. Sandbox logs show provider startup, command setup, and repeated getMe/getUpdates calls, but in this run there are no clear logs indicating that the incoming message was routed to the agent or that any outbound sendMessage was issued in response. From the user's perspective, enabling the Telegram channel reports success, yet the bot silently ignores messages and never responds, indicating a remaining defect in the Telegram ↔ agent wiring despite the bridge and poller now running.

Environment

• Device: Ubuntu 22.04 (Brev host)
• OS: Ubuntu 22.04.5 LTS (x86_64)
• Node.js: v22.22.3
• npm: 10.9.8
• Docker: 29.5.2
• OpenShell CLI: 0.0.44 (docker)
• NemoClaw: v0.0.54
• OpenClaw: 2026.5.22 (a374c3a)
• Egress to api.telegram.org: verified working from this Brev host

Preconditions

1. NemoClaw installed via:

   export NEMOCLAW_INSTALL_TAG=v0.0.54
   export NEMOCLAW_NON_INTERACTIVE=1
   export NEMOCLAW_PROVIDER=build
   export NVIDIA_API_KEY=...
   curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

2. Telegram environment variables set in shell:

   export TELEGRAM_BOT_TOKEN=...
   export TELEGRAM_CHAT_ID=...
   export TELEGRAM_AUTHORIZED_CHAT_IDS=...

3. Bot token validated:

   curl "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/getMe"
   # → {"ok":true,"result":{"id":<your_id>,"is_bot":true,"username":"<your_bot>",...}}

Steps to Reproduce

1. Onboard a fresh sandbox without GPU:

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

2. Add Telegram channel using the env vars above:

   nemoclaw tg-test channels add telegram

   CLI reports success (channel registered).

3. Rebuild the sandbox to apply the channel:

   nemoclaw tg-test rebuild --yes

   Wait until nemoclaw tg-test status reports healthy.

4. (Optional sanity check) Inside openshell-tg-test container, look for a Telegram bridge and directory:

   CID=$(docker ps --format '{{.ID}} {{.Names}}' | awk '$2 ~ /openshell-tg-test/ {print $1}')
   docker exec "$CID" ps aux | grep -iE 'telegram|tgbot|bridge' | grep -v grep
   docker exec "$CID" ls -la /sandbox/.openclaw/telegram/

   Observed: no explicit telegram/bridge-named process; directory exists but only . and ...

5. Send a test message to the bot from the Brev host:

   curl -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" \
       -d "chat_id=${TELEGRAM_CHAT_ID}" \
       --data-urlencode "text=hello bot please reply"

   Observed:

   {
     "ok": true,
     "result": {
       "message_id": 42,
       "from": {
         "id": 8734869089,
         "is_bot": true,
         "username": "prachi_test_bot"
       },
       "chat": {
         "id": 8388960805,
         "first_name": "Prachi",
         "last_name": "Shevate",
         "type": "private"
       },
       "date": 1780096998,
       "text": "hello bot please reply"
     }
   }

   (Telegram accepts and delivers the message.)

6. Wait ~60–120 seconds, then inspect sandbox logs for Telegram activity:

   nemoclaw tg-test logs --tail 200 | grep -iE 'telegram|update_id|message_id|chat' || echo "no telegram logs"

   Observed (examples):

   • Network policy initially denies, then allows Telegram bot traffic:

     [OCSF] NET:OPEN  DENIED  /usr/local/bin/node -> api.telegram.org:443 [reason:endpoint not in policy 'clawhub'...]
     [OCSF] NET:OPEN  ALLOWED /usr/local/bin/node -> api.telegram.org:443 [policy:telegram_bot]
     

   • Telegram provider starts and configures commands:

     2026-05-29T23:20:52.872+00:00 [telegram] [default] starting provider (@prachi_test_bot)
     2026-05-29T23:20:53.271+00:00 [telegram] menu text exceeded the conservative 5700-character payload budget;
                                              shortening descriptions to keep 59 commands visible.
     

   • Polling ingress is started:

     2026-05-29T23:20:54.022+00:00 [telegram] [diag] isolated polling ingress started
                                              spool=/sandbox/.openclaw/telegram/ingress-spool-default
     

   • Repeated getMe / getUpdates calls:

     [OCSF] HTTP:GET  ALLOWED GET  http://api.telegram.org:443/bot[CREDENTIAL]/getMe       [policy:telegram_bot]
     [OCSF] HTTP:POST ALLOWED POST http://api.telegram.org:443/bot[CREDENTIAL]/getUpdates  [policy:telegram_bot]
     (repeats over time)
     

7. Observe the Telegram chat in the client (mobile or desktop) for any response from the bot to the "hello bot please reply" message.

Expected Result

After step 3, the Telegram bridge is fully active for sandbox tg-test:

• It long-polls getUpdates for the configured bot token.
• It consumes incoming messages for TELEGRAM_CHAT_ID=8388960805.

After step 5:

• The message "hello bot please reply" is received by the bridge and passed to the tg-test agent.
• The agent generates a response and the bridge sends it back to Telegram.

Within ≤ 30–60 seconds of sending the message:

• The user sees a reply from prachi_test_bot in the Telegram chat (e.g., a greeting from the agent).
• Logs show both the incoming update (update_id, chat/message fields) and an outgoing sendMessage back to Telegram.

Actual Result (current build)

• Telegram provider and ingress do start successfully:

  • Logs show [telegram] [default] starting provider (@prachi_test_bot) and isolated polling ingress started spool=/sandbox/.openclaw/telegram/ingress-spool-default.
  • Network logs show repeated getMe and getUpdates requests to api.telegram.org under policy:telegram_bot.

• Telegram accepts test messages from the host:

  • sendMessage returns ok:true with valid message_id and correct chat id (8388960805).

• However, no reply ever appears in the Telegram chat from the sandbox agent:

  • Waiting 60–120 seconds after sending "hello bot please reply" yields no visible response in the Telegram client.
  • Sandbox logs show polling and command setup, but (in this run) no clear log entries for an incoming update with message_id=42 nor any subsequent outbound sendMessage triggered by the agent.

From the user's perspective, "Telegram channel enabled" appears successful in NemoClaw, but the end-to-end chat experience remains broken: messages reach Telegram but do not result in any agent responses.

Notes / Attachments

Suggested attachments (from this run):

• tg-test_logs_telegram.txt – full nemoclaw tg-test logs excerpt including Telegram provider startup, network policy decisions, and getUpdates calls.
• telegram_send_message_hello.json – raw sendMessage response showing message_id=42 and chat id 8388960805.
• env_telegram_brev.txt – environment summary (Brev instance type, NemoClaw/OpenClaw versions, getMe output).