Summary

Messaging integrations (Discord, Slack, Telegram) should all follow the Telegram bridge pattern: run on the host, relay messages to the sandbox via OpenShell SSH. Credentials never enter the sandbox.

Current state

Target state

All messaging integrations run as host-side bridges:

1. Bridge process runs on the host with access to ~/.nemoclaw/credentials.json
2. Connects to the messaging API directly (tokens never enter sandbox)
3. Relays messages to the sandbox agent via OpenShell SSH
4. Credentials can be changed anytime by restarting the bridge

This eliminates the entire class of problems around:

• Passing tokens through sandbox creation env vars
• Immutable config blocking token writes (fix: Discord bot token write fails against immutable openclaw.json #599, Discord bot token set - Error: EACCES: permission denied, copyfile '/sandbox/.openclaw/openclaw.json #606)
• configWrites: False workaround
• Can't update credentials without recreate (feat: host-side channel bridge architecture for all messaging integrations #618 original scope)

Existing work

• scripts/telegram-bridge.js — proven host-side bridge pattern
• PR feat: add Discord bridge (host-side, Telegram-style) #422 — community Discord bridge (host-side, Telegram-style)
• PR feat(scripts): add host-side Discord bridge #458 — community Discord bridge from phanisaimunipalli

Proposed approach

1. Generalize telegram-bridge.js into a reusable bridge framework
2. Add Discord bridge using the same pattern
3. Add Slack bridge using the same pattern
4. Remove Discord/Slack token passthrough from sandbox creation (no longer needed)
5. Remove configWrites: False from Dockerfile (no longer needed)
6. Update start-services.sh to manage all bridges
7. Document host-side bridge as the canonical pattern for messaging integrations

Context

The current env-var-into-sandbox approach (#601, #616) was a narrow fix. This issue reframes the architecture to match what Telegram already does successfully.