[Linux][Agent&Skills] Second sandbox Slack bridge silently fails — Socket Mode events routed only to first registered sandbox on shared gateway

[mercl-lau]

Description

When two sandboxes on the same OpenShell gateway both configure Slack bridge, only the first sandbox receives Slack Socket Mode events. The second sandbox's Slack connection establishes successfully and nemoclaw status shows the bridge as "running", but it never receives any Slack events. No error or warning is surfaced to the user.

Environment

Device:        Linux server
OS:            Ubuntu 24.04
Architecture:  x86_64
Node.js:       v22.22.3
npm:           10.9.8
Docker:        29.5.2
OpenShell CLI: 0.0.44
NemoClaw:      v0.0.60
OpenClaw:      2026.5.27

Steps to Reproduce

1. Onboard Sandbox A (hermes-tete) with Slack channel enabled and Slack bot token configured
2. Verify Sandbox A receives Slack messages normally
3. Onboard Sandbox B (claw-jinilet) on the SAME gateway with a different Slack app/bot token
4. Verify both sandboxes show Slack bridge as "running" in nemoclaw status
5. Send a Slack message to Sandbox B's bot
6. Observe that Sandbox B receives nothing — events are routed to Sandbox A only

Expected Result

Either:

• (a) Both sandboxes receive their respective Slack events via their own bot tokens, OR
• (b) The second onboard warns or errors that Slack Socket Mode is already occupied on this gateway, guiding the user to the limitation

Actual Result

Silent failure — second sandbox Slack bridge appears healthy (nemoclaw status shows bridge "running") but never receives any Slack events. All Socket Mode events are routed exclusively to the first registered sandbox (Sandbox A). No error, no warning, no log entry indicating the conflict.

Logs

No error logs observed — this is part of the problem. Both sandboxes show healthy Slack bridge status. The failure is completely silent.

Analysis

Slack Socket Mode maintains a single WebSocket connection per bot token per gateway. When two sandboxes register on the same gateway, the first sandbox's Socket Mode connection captures the event routing. The second sandbox's connection may establish at the transport level but the gateway does not multiplex or route events to it.

This is likely an OpenShell/OpenClaw gateway architectural limitation where Slack Socket Mode can only have one active consumer per gateway instance.

Suggested Fix

• Option 1: Support per-sandbox Slack event routing at the gateway level (route events based on bot token / app ID to the correct sandbox)
• Option 2: Detect the conflict at onboard time and surface a clear error: "Slack Socket Mode is already in use by sandbox X on this gateway. Only one sandbox can use Slack per gateway."
• Option 3: Document the limitation clearly in the onboard flow and docs

---

NVB#6282574

[wscurran]

✨ Thanks for submitting this detailed issue about the second sandbox's Slack bridge failing to receive events on a shared gateway. This identifies a bug in the sandbox and messaging areas that affects the Slack integration.