discord-mcp-bridge
Heterogeneous AI collaboration over Discord — Claude Code and OpenAI Codex CLI in the same channel.
简体中文 README
A Discord ↔ MCP bridge forked from Anthropic's official claude-plugins-official/discord plugin (v0.0.4, Apache-2.0), with one addition that unlocks a new use case: AI CLIs that don't subscribe to MCP server-push notifications can now participate in the same Discord channel as Claude Code.
Upstream Claude Code behavior is preserved unchanged — this fork is strictly additive.
Why this exists
Three layers of constraints stacked up until we forked:
1. Third-party AI CLIs cannot reach Claude Code through subscription channels. Tools like OpenAI Codex CLI, Aider, OpenClaw, and other community CLIs don't speak the Anthropic-specific notifications/claude/channel MCP extension that Claude Code uses for server-push notifications. It is not part of the public MCP spec. So even when both sit on the same machine, they can't share a "topic" the way two Claude Code instances can.
2. Reusing Anthropic's Discord plugin for Codex does not work by itself. The official claude-plugins-official/discord plugin gives Claude Code a clean inbound channel — Discord messages arrive as MCP notifications/claude/channel events, and Claude replies via MCP tool calls. It works because both ends speak the same notification protocol. But: it only works for Claude Code. A second Codex CLI process on the same host cannot tap into that notification stream.
3. A second Discord bot for Codex alone doesn't solve it either. You could give Codex its own Discord bot, but Codex CLI itself doesn't subscribe to MCP server-push notifications — it polls only on tool-call boundaries. So a vanilla MCP Discord server wouldn't trigger Codex into a turn when a new Discord message arrives; the message would sit in the bridge's memory until Codex happened to call a tool.
Our patch: alongside the upstream MCP notification path (untouched), the bridge can also inject inbound messages into a named tmux session via tmux send-keys -l (literal-keys mode, no shell, no key-name interpretation). Run Codex CLI inside that tmux session and each Discord message arrives as a fresh user prompt — Codex reacts on real time, without any change to Codex itself.
Result: a single Discord channel with Claude Code + OpenAI Codex CLI both reading and replying as first-class participants. Plus the human operator. Plus whatever future CLI you can pipe into a tmux session.
The result we wanted, in one line: heterogeneous AI teams that actually collaborate on real engineering tasks — not just take turns being prompted.
What this fork changes vs upstream v0.0.4
Two minimal, additive changes — nothing removed, nothing broken:
| # | Change | Why |
|---|
| 1 | DISCORD_TMUX_TARGET env var | When set, inbound messages that pass the access gate are also injected as keystrokes into the named tmux session (tmux send-keys -l, literal mode). Lets non-Claude CLIs react to Discord. |
| 2 | Replaced msg.author.bot prefilter with self-only check (msg.author.id === client.user?.id) | Multi-AI groups need to see other bots' messages; behavior protocol (AGENTS.md / CLAUDE.md) decides reply, not the plugin. |
Together, these two changes are roughly 30 lines of behavior-changing code.
The upstream notifications/claude/channel push path is preserved untouched. Claude Code consumes this server identically to the original.
Key commits in this fork:
dc03da8 — Fork + tmuxInject92c8554 — Drop msg.author.bot prefilterc5d1347 — Add codex/ setup helpers
Quick start
Path A — Claude Code (upstream-compatible, no fork needed)
If you only want Claude Code on Discord, the official plugin remains the best default (/plugin install discord@claude-plugins-official). This fork's extra value is the optional tmux path for non-Claude CLIs and multi-AI bot visibility.
This fork's Claude Code path is byte-identical to upstream for the notification flow. The full upstream setup walkthrough (bot creation → token → permissions → pairing → allowlist) lives in ACCESS.md.
Path B — OpenAI Codex CLI (the reason this fork exists)
Codex CLI doesn't subscribe to MCP server-push, so we run it inside a tmux session and let the bridge type Discord messages into Codex's stdin via tmux send-keys -l.
1. Clone & install on the host running Codex
git clone https://github.com/robustfengbin/discord-mcp-bridge.git ~/codex-discord
cd ~/codex-discord && bun install
Requires Bun: curl -fsSL https://bun.sh/install | bash.
2. Provide credentials in a private state dir
mkdir -p ~/codex/discord-state && chmod 700 ~/codex/discord-state
echo 'DISCORD_BOT_TOKEN=<your-token>' > ~/codex/discord-state/.env
chmod 600 ~/codex/discord-state/.env
