Repository navigation
feat: host-side channel bridge architecture for all messaging integrations #618
Description
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
| Integration | Where it runs | Token location | Problems |
|---|---|---|---|
| Telegram | Host (bridge script) | Host only | None — this is the target pattern |
| Discord | Sandbox (OpenClaw plugin) | Passed as sandbox env var | Immutable config issues (#599, #606), can't update without recreate |
| Slack | Sandbox (OpenClaw plugin) | Passed as sandbox env var | Same as Discord |
Target state
All messaging integrations run as host-side bridges:
- Bridge process runs on the host with access to
~/.nemoclaw/credentials.json - Connects to the messaging API directly (tokens never enter sandbox)
- Relays messages to the sandbox agent via OpenShell SSH
- 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: Falseworkaround- 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
- Generalize
telegram-bridge.jsinto a reusable bridge framework - Add Discord bridge using the same pattern
- Add Slack bridge using the same pattern
- Remove Discord/Slack token passthrough from sandbox creation (no longer needed)
- Remove
configWrites: Falsefrom Dockerfile (no longer needed) - Update
start-services.shto manage all bridges - 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.
Activity
[-]feat: allow updating sandbox credentials without full recreate[/-][+]feat: host-side channel bridge architecture for all messaging integrations[/+]feat: host-side bridge framework with Discord support
wscurran commentedon Apr 20, 2026
The messaging architecture shipped in a different direction — channels are now configured during
nemoclaw onboard, tokens are registered with OpenShell providers, and runtime delivery stays under OpenShell control rather than host-side bridge scripts. The host-side bridge pattern this proposes has been superseded by that approach. Closing for housekeeping.