Description

The gateway opens and maintains WebSocket connections to Slack's socket-mode endpoint even when the Slack channel is explicitly configured with "enabled": false. This creates zombie connections that fail on every ping/pong cycle and destabilize other channel providers.

Version

openclaw@2026.2.26

Steps to Reproduce

1. Configure Slack channel with "enabled": false and valid botToken + appToken
2. Start the gateway
3. Observe gateway.err.log

Expected Behavior

No WebSocket connections should be opened for disabled channels.

Actual Behavior

The gateway initiates socket-mode connections despite enabled: false. The connection is established but ping/pong frames are not properly serviced, producing a repeating cycle:

[WARN] socket-mode:SlackWebSocket:N A pong wasn't received from the server before the timeout of 5000ms!
[WARN] socket-mode:SlackWebSocket:N A ping wasn't received from the server before the timeout of 30000ms!

This repeats every ~15-17 minutes with incrementing connection numbers (observed :1 through :22+).

Impact

• Collateral damage to other channels: The Telegram provider was repeatedly crashing and restarting alongside the Slack reconnect cycle, causing ~2 minute message latency for Telegram users.
• Log bloat: gateway.err.log grew to ~19 million lines from the pong timeout spam combined with a TimeoutOverflowWarning (timer value 35952828857 overflows 32-bit signed int).

Workaround

Disabling Slack and restarting the gateway stabilized Telegram immediately. However, enabled: false alone does not prevent the WebSocket from being opened — the bug persists until the gateway is restarted without valid Slack tokens.

Config (redacted)

"slack": {
  "mode": "socket",
  "enabled": false,
  "botToken": "xoxb-...",
  "appToken": "xapp-...",
  "groupPolicy": "allowlist",
  "nativeStreaming": true,
  "streaming": "partial"
}

Environment

• macOS Darwin 25.3.0
• Node.js 22.x
• openclaw@2026.2.26