Description

A NemoClaw sandbox onboarded with Discord channel enabled comes up in a degraded state where the bot can send messages via Discord REST API but never establishes the Discord Gateway WebSocket connection (wss://gateway.discord.gg). As a result the bot receives ZERO MESSAGE_CREATE / app_mention events from Discord, and a user @mention or DM never reaches the bot — silent black-hole. The bot looks alive from outside (REST polling /users/@me + /oauth2/applications/@me succeeds every 60s, nemoclaw <name> status returns Phase=Ready, OCSF policy allows discord.com / *.discord.gg / cdn.discordapp.com per the discord preset) but is functionally one-way only.

This means the entire inbound half of the Discord messaging channel is broken — Bot DM, Group/Channel chat, Multi-turn context, and Sustained-session validation all fail at the inbound step.

Possible related: NVBug 6173802 / #3477 (Merc Lau) — outbound CONNECT to discord.com / gateway.discord.gg via the openshell internal proxy 10.200.0.1:3128 returns HTTP 403. If the bot's WebSocket client routes through that proxy (and silently fails on the 403 CONNECT instead of falling back to direct), 6173802 would be the root cause and this bug closes as a duplicate. However, the bot's REST traffic clearly goes direct (OCSF logs show NET:OPEN /usr/local/bin/node(362) -> discord.com:443 ALLOWED via policy:discord engine:opa, no proxy hop), so the WS client may also be going direct and silently failing for a different reason. Dev triage to determine root cause.

Environment

Device:        DGX Station #1 (galaxy-sku2-018)
OS:            Ubuntu 24.04.4 LTS
Architecture:  aarch64
Node.js:       v22.22.3
npm:           10.9.8
Docker:        29.5.0
OpenShell CLI: 0.0.39
NemoClaw:      v0.0.46
OpenClaw:      2026.4.24
Sandbox:       discord-sb (uptime 2+ hours when observed)
Sandbox image: openshell/sandbox-from:1779263934

Steps to Reproduce

1. nemoclaw onboard --name discord-sb --fresh -y
   • [3/8] Local Ollama (fix: update all repo references to NVIDIA/NemoClaw #7), model llama3.2:1b
   • [5/8] toggle Discord (feature: custom settings for using build endpoints #2)
   • Paste Discord Bot Token, Server ID 1490999514902036564, reply mode Y (@mentions only), skip User ID allowlist
   • [8/8] accept Balanced + default presets (discord auto-included)
2. After onboard completes, confirm the bot is alive:

   nemoclaw discord-sb status      # → Phase=Ready, Agent OpenClaw v2026.4.24, Policies include discord
   nemoclaw discord-sb logs        # → repeating ALLOWED GET http://discord.com:443/api/v10/users/@me every 60s

3. From a separate Discord user account that IS a member of the configured guild, @mention the bot in any channel the bot can see (e.g. #nemoclaw of guild 1490999514902036564):

   @testnemoclaw hello test
   

4. Check the bot logs and the bot's reply behavior.

Expected Result

1. Bot establishes Discord Gateway WebSocket within 2 minutes of onboard:
   • NET:OPEN to gateway.discord.gg:443 visible in OCSF logs
   • openclaw agent.log (or equivalent) contains Discord gateway READY line
2. After step-3 @mention, bot logs show:
   • MESSAGE_CREATE / app_mention received from user X in channel Y
   • Inference invoked, reply generated
   • "Sent via Discord" or equivalent acknowledgement
3. Bot replies in the channel @mentioning back the user, within ~30s.

(Paraphrased from DevTest T5910682's expected results for steps 7a-15.)

Actual Result

1. NO NET:OPEN to gateway.discord.gg:443 in OCSF logs over a 2+ hour window. grep for gateway.discord.gg / *.discord.gg / wss / WEBSOCKET in 200+ tail lines: zero matches.

2. The only Discord traffic from the bot daemon is the periodic REST poll every 60s:

   [...] ALLOWED /usr/local/bin/node(362) -> discord.com:443 [policy:discord engine:opa]
   [...] ALLOWED GET http://discord.com:443/api/v10/users/@me [policy:discord engine:l7]
   [...] ALLOWED GET http://discord.com:443/api/v10/oauth2/applications/@me [policy:discord engine:l7]
   

3. Bot daemon process tree inside the sandbox shows only:

   /opt/openshell/bin/openshell-sandbox      (PID 1, root)
   sleep infinity                            (PID 161, sandbox user)
   openclaw                                  (PID 353, sandbox user)
     └─ openclaw-gateway                     (PID 362, sandbox user)
   

   No separate Discord WebSocket client process. Discord WS would normally live inside the openclaw or openclaw-gateway process; we see no NET:OPEN to gateway.discord.gg from either PID.

4. After 30+ minutes of "watch for @mention" tail, plus a direct user-side @mention attempt confirmed sent, the bot logs contain ZERO MESSAGE_CREATE / app_mention / inbound-message events. Bot does not reply.

5. Cross-check on the wire path via direct REST API as another user:

   • The bot CAN send messages out via REST (POST /channels/<id>/messages with bot token succeeds, message appears in #nemoclaw — verified 2026-05-20 10:51:50 with bot author testnemoclaw bot=true).
   • The bot CANNOT see incoming MESSAGE_CREATE events because no Gateway WS exists for it to subscribe to.

6. openclaw.json config IS correct:

   "channels": {
     "discord": {
       "accounts": {
         "default": {
           "token": "openshell:resolve:env:DISCORD_BOT_TOKEN",
           "enabled": true
         }
       },
       "guilds": { "1490999514902036564": { "requireMention": true } },
       "enabled": true
     }
   }

7. openclaw process env shows DISCORD_BOT_TOKEN resolves to openshell:resolve:env:v6695330198429962168_DISCORD_BOT_TOKEN (openshell credential indirection — token is actually fetched on demand). The fact that REST GETs to /users/@me succeed proves the token resolves and authenticates correctly.

NVB#6195454