终端多路通信服务

tmux-bridge-mcp 是一个独立的 MCP 服务器,允许 AI 代理(如 Claude Code、Gemini CLI、Codex、Kimi CLI)通过 tmux 面板相互通信。它直接与 tmux 交互,无需除 tmux 本身外的外部依赖。

  • by howardpen9
  • TypeScript
  • 本地部署
  • 107 星标
  • 更新于
在 GitHub 查看 howardpen9/tmux-bridge-mcp

使用说明

tmux桥mcp

英语 | 简体中文

一个独立的MCP服务器,允许AI代理(Claude Code、Gemini CLI、Codex、Kimi CLI)通过tmux窗格相互通信。它直接与tmux通信,除了tmux本身之外没有外部依赖关系。

🖥️ 什么是tmux?

终端多路复用器 是一个 终端复用器 --它允许您将一个终端窗口拆分为多个 窗格,每个都独立运行自己的进程。把它想象成你终端的“类固醇标签”。

+-------------------------------+
|  Pane 1       |  Pane 2       |
|  Claude Code  |  Codex        |
|  writing code |  reviewing    |
|               |               |
+---------------+---------------+
|  Pane 3       |  Pane 4       |
|  Gemini CLI   |  tail -f logs |
|  researching  |  monitoring   |
+-------------------------------+

每个窗格都是一个完整的终端。你可以让Claude Code在一台机器上运行,Codex在另一台机器中运行,Gemini在第三台机器上——所有这些都可以在同一时间看到,都在同一台计算机上运行。

问题: 这些窗格不能相互交谈。窗格1中的代理不知道窗格2中发生了什么。

tmux桥修复了这个问题。 它使每个代理都能够读取、键入消息并将其发送到任何其他窗格中。

⚡ 你可以用tmux桥做什么?

安装后,您的AI代理可以:

行动 方式 示例
看看另一个特工在做什么 tmux_read 阅读Codex窗格的最后20行
将任务发送给另一个代理 tmux_message + tmux_keys 告诉克劳德查看文件
协调多代理工作流 链工具调用 Gemini研究->Claude实施->Codex审查
监控流程 tmux_read 在shell窗格上 查看构建日志、测试输出、服务器状态
按角色标记窗格 tmux_name 名称窗格“claude”、“codex”、“gemini”便于定位

所有这些都是通过标准的MCP工具调用实现的——您的代理不需要学习任何新的语法。如果它支持MCP,它已经知道怎么做了。

🤖 支持的代理

测试并记录

代理 连接 安装路径
Claude 代码 本地MCP(stdio) claude mcp add -s user / ~/.claude.json
Codex 命令行界面 本地MCP(stdio) codex mcp add
开源代码 本地MCP(stdio) ~/.config/opencode/opencode.json(c) (mcp 按键)
编程伙伴 本地MCP(stdio) codebuddy mcp add -s user / ~/.codebuddy/.mcp.json
GitHub Copilot命令行界面 本地MCP(stdio) copilot mcp add / ~/.copilot/mcp-config.json
Grok 构建 本地MCP(stdio) grok mcp add -s user / ~/.grok/config.toml
Gemini CLI 本地MCP(stdio) ~/.gemini/settings.json
化学CLI v1.26+ 本地MCP(kimi mcp add) kimi mcp add
化学CLI 旧版 旧版包装(kimi-tmux) 包装器二进制文件

应该有效(任何MCP兼容的代理)

代理人 备注
光标 在设置中支持MCP服务器
风帆冲浪(Codeium) MCP服务器支持
助手 社区MCP支持
Continue.dev MCP服务器支持
克莱恩 使用MCP进行VS代码扩展
Roo代码 带MCP的熟料叉
任何shell脚本或进程 读取窗格输出 tmux_read,不需要MCP

tmux网桥与 支持MCP over stdio的任何代理。如果您的代理未列出,请尝试添加MCP配置——它可能会正常工作。

💡 为什么

当你在不同的终端中运行多个AI代理时,它们是独立工作的。您最终会在它们之间复制粘贴上下文,手动传递问题和答案,或者忘记每个代理正在做什么。

tmux桥通过赋予每个代理以下能力来解决这个问题 在任何其他终端窗格中读取、键入和发送消息 --通过标准MCP工具调用以编程方式进行。

使用案例:

  • 代码审查流程 --Claude Code在一个窗格中编写代码,Codex在另一个窗格进行审核,结果自动返回
  • 多模型推理 --请双子座进行研究,将研究结果反馈给克劳德,让食品法典委员会验证实施情况
  • 并行工作流 --多个Claude Code实例,每个实例处理大型任务的不同部分,通过窗格消息进行协调
  • 监控 --代理从读取日志输出 tail -f 窗格并实时对错误做出反应

您需要什么:

要求 为什么
终端多路复用器 承载窗格的终端多路复用器——这是通信通道
Node.js 18+ 运行MCP服务器
至少一个MCP兼容代理 Claude Code、Codex、OpenCode、CodeBuddy、Copilot CLI、Grok Build、Gemini CLI或Kimi CLI v1.26+

如果您已经使用tmux并行运行多个代理,tmux桥只会让它们相互了解。

😩 无tmux网桥

您在一个窗格中运行Claude Code,在另一个窗格运行Codex。Claude完成了一个函数的编写,您希望Codex对其进行审查。实际情况如下:

  1. 你读了克劳德的输出。向上滚动。复制相关部分。
  2. 切换到Codex的窗格。粘贴进去。键入“查看此代码”
  3. 食品法典委员会提供反馈。你复制它。
  4. 切换回克劳德。粘贴Codex的反馈。“解决这些问题。”
  5. 对每一轮审查重复上述步骤。

你就是信息总线。 每次交互都会通过剪贴板进行。您不再编写代码,而是在代理之间路由上下文。当3个以上的代理运行时,这在几分钟内变得无法管理。

🤔 为什么不是LangChain/CrewAI/A2A?

方法 它要求你做什么 tmux桥接差异
朗链/CrewAI/AutoGen 在他们的框架内重写你的工作流。你的代理必须是编排层中的Python对象。 您继续按原样使用Claude Code、Codex、Gemini CLI。没有框架,没有SDK,没有重写。
谷歌A2A协议 等待代理采用专为分布式网络代理设计的新协议规范。 今天适用于任何MCP代理。无需通过协议。
自定义WebSocket/HTTP胶水 构建并维护您自己的IPC层。处理序列化、发现、错误处理。 零基础设施。tmux是传输工具,它已经在运行了。
共享文件/管道 举办自己的大会。每个代理都需要自定义工具来读/写。 标准MCP工具。任何说MCP的特工都会立即获得跨窗格超能力。

关键见解: 你不需要多智能体 框架.你需要你现有的代理人 见面.tmux桥恰好添加了这一点——tmux上的一个薄MCP层——仅此而已。

🚀 快速开始

先决条件: 必须安装tmux 3.2+和Node.js 18+。

配置所有代理的一个命令:

npx tmux-bridge-mcp setup

此功能会自动检测您计算机上的Claude Code、Codex、OpenCode、CodeBuddy、Copilot CLI、Grok Build、Gemini CLI和Kimi CLI,然后为每个配置写入正确的MCP配置。几秒钟内完成。

验证它是否有效:

npx tmux-bridge-mcp --help

您应该看到版本和可用命令。重新启动AI代理以激活新工具。

看看它在行动:

npx tmux-bridge-mcp demo

打开3窗格tmux会话并运行实时跨窗格通信演示。

Manual setup (if you prefer)

1.安装tmux

brew install tmux    # macOS
apt install tmux     # Linux

2.添加到代理的MCP配置中

{
  "mcpServers": {
    "tmux-bridge": {
      "command": "npx",
      "args": ["-y", "tmux-bridge-mcp"]
    }
  }
}

重新启动您的代理。它现在有9个用于跨窗格通信的MCP工具。

🔄 更新

# If installed globally
npm update -g tmux-bridge-mcp

# If using npx (auto-updates, but to force latest)
npx tmux-bridge-mcp@latest

# Check your current version
npx tmux-bridge-mcp --version

更新后,重新启动代理以获取新版本。如果你使用 npx 在MCP配置中,它缓存包--run npx --yes tmux-bridge-mcp@latest 一旦获取了最新信息,您的代理将在下次启动时使用它。

🏗️ 运作原理

tmux网桥作为MCP服务器在stdio上运行。它直接调用tmux(capture-pane, send-keys, list-panes等等)——没有中间CLI层。

MCP path (Gemini, Claude Code, Codex, any MCP client):
+--------------+  MCP/stdio  +---------------+  tmux API  +--------------+
|  MCP Agent   |<----------->|  tmux-bridge  |<---------->|  tmux panes  |
+--------------+             |  MCP server   |            +--------------+
                             +---------------+

CLI path (Kimi):
+--------------+  --print    +---------------+  tmux API  +--------------+
|  Kimi CLI    |<----------->|  kimi-tmux    |<---------->|  tmux panes  |
+--------------+  tool parse |  adapter      |            +--------------+
                             +---------------+

所有跨窗格交互都遵循 阅读行为阅读 工作流:

步骤 行动 目的
1 tmux_read 读取目标窗格(满足读取保护)
2 tmux_message / tmux_type 键入您的消息或命令
3 tmux_read 验证文本是否正确着陆
4 tmux_keys 按Enter键提交
-- 停止 不要投票。另一个代理直接回复到您的窗格中。

读取保护在MCP层强制执行: tmux_type, tmux_message,以及 tmux_keys 除非你打电话,否则会失败 tmux_read 首先在目标窗格上。

⚙️ 每个代理的设置

Gemini CLI(原生MCP)

增添 ~/.gemini/settings.json:

{
  "mcpServers": {
    "tmux-bridge": {
      "command": "npx",
      "args": ["tmux-bridge-mcp"]
    }
  }
}

克劳德代码(原生MCP)

添加到您的项目 .mcp.json 或全局MCP配置:

{
  "mcpServers": {
    "tmux-bridge": {
      "command": "npx",
      "args": ["tmux-bridge-mcp"]
    }
  }
}

Codex(本地MCP)

按照Codex MCP设置文档添加到MCP配置中:

{
  "mcpServers": {
    "tmux-bridge": {
      "command": "npx",
      "args": ["tmux-bridge-mcp"]
    }
  }
}

开源代码

opencode mcp add 是互动的。 tmux-bridge-mcp setup 直接写入 ~/.config/opencode/opencode.json (或 .jsonc):

{
  "mcp": {
    "tmux-bridge": {
      "type": "local",
      "command": ["npx", "-y", "tmux-bridge-mcp"],
      "enabled": true
    }
  }
}

CodeBuddy(腾讯)

codebuddy mcp add -s user tmux-bridge -- npx -y tmux-bridge-mcp

回退配置路径: ~/.codebuddy/.mcp.json (标准 mcpServers JSON)。

GitHub Copilot命令行界面

copilot mcp add tmux-bridge -- npx -y tmux-bridge-mcp

回退配置路径: ~/.copilot/mcp-config.json:

{
  "mcpServers": {
    "tmux-bridge": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "tmux-bridge-mcp"],
      "tools": ["*"]
    }
  }
}

Grok 构建

grok mcp add -s user tmux-bridge -- npx -y tmux-bridge-mcp

撤退TOML in ~/.grok/config.toml:

[mcp_servers.tmux-bridge]
command = "npx"
args = [
    "-y",
    "tmux-bridge-mcp",
]
enabled = true

化学CLI

# Check your Kimi version
kimi --version
# v1.26+ → use native MCP (recommended)
# older  → use kimi-tmux wrapper

原生MCP(推荐,v1.26+):

kimi mcp add tmux-bridge -- npx tmux-bridge-mcp

添加后,Kimi直接使用所有tmux桥接工具,无需适配器。

传统包装器(旧版本):

对于没有本地MCP的Kimi CLI版本, kimi-tmux 通过将系统指令作为提示符注入,在中运行Kimi来弥合差距 --print 模式,从输出中解析工具调用块,并通过tmux执行它们。

kimi-tmux "list all tmux panes"
kimi-tmux "ask the agent in codex pane to review src/auth.ts"
kimi-tmux "read what claude is working on"
kimi-tmux --rounds 3 "send a message to gemini and wait for the result"

🔧 工具参考

工具 说明
tmux_list 列出所有带有目标ID、进程、标签和工作目录的窗格
tmux_read 从窗格中读取最后N行(满足读取保护)
tmux_type 在窗格中键入文本而不按Enter键(需要事先阅读)
tmux_message 发送带有自动前缀发件人信息的邮件(需要事先阅读)
tmux_keys 发送特殊密钥——Enter、Escape、C-C等。(需要事先阅读)
tmux_name 标记一个窗格以便于定位(例如,“claude”、“gemini”)
tmux_resolve 按标签查找窗格ID
tmux_id 打印当前窗格的tmux ID
tmux_doctor 诊断tmux连接问题

目标可以是窗格ID(%0),会话:window.pane(main:0.1),或标签(claude).

📖 示例

让克劳德审查一份文件(来自双子座)

tmux_list()
tmux_read(target="claude", lines=20)
tmux_message(target="claude", text="Please review src/auth.ts for security issues")
tmux_read(target="claude", lines=5)
tmux_keys(target="claude", keys=["Enter"])

多代理协调(来自Kimi)

kimi-tmux "tell the claude pane to run the test suite"
kimi-tmux "ask gemini to summarize the test results in claude's pane"

多代理布局

+-----------------------------------------------------------+
| tmux session                                              |
|                                                           |
| +------------+ +------------+ +----------+ +-----------+  |
| | Claude Code | |   Codex    | | Gemini   | |   Kimi    | |
| |  (MCP)     | |  (MCP)     | |  (MCP)   | |(kimi-tmux)| |
| |            | |            | |          | |           |  |
| | label:     | | label:     | | label:   | | label:    |  |
| | claude     | | codex      | | gemini   | | kimi      |  |
| +-----+------+ +-----+------+ +----+-----+ +-----+-----+ |
|       +---------------+-----------+--------------+        |
|           tmux-bridge (direct tmux IPC, no deps)          |
+-----------------------------------------------------------+

🌐 环境变量

变量 描述 默认值
TMUX_BRIDGE_SOCKET 覆盖tmux服务器套接字路径 从自动检测到 $TMUX
KIMI_PATH 通往 kimi 二进制(仅限kimi tmux) kimi (在PATH中)

🔒 安全模型

tmux网桥是为 单机上的本地开发。它假设所有连接的MCP代理都是可信的:

  • 任何代理都可以读取或写入 任何窗格 在tmux服务器中,没有每个窗格的访问控制。
  • 这个 阅读保护 (必须 tmux_read 之前 tmux_type/tmux_keys)是一种防止盲目打字的测序辅助工具。它是 不是安全边界.
  • 通过以下方式设置窗格标签 tmux_name 是 未认证 --任何代理都可以标记或重新标记任何窗格。
  • 代理之间没有加密或身份验证。通信通过tmux自己的IPC(Unix套接字)进行。

不要在多租户环境中使用tmux网桥 或者通过网络公开tmux套接字。它是为常见情况而构建的:一个开发人员在自己的机器上并行运行多个AI代理。

📝 系统指令

对于支持自定义系统提示的代理,请使用 system-instruction/smux-skill.md它教授阅读动作阅读工作流程,并记录了所有可用的MCP工具。

🔗 相关项目

项目 方法 重点
smux tmux技能+bash CLI 与代理无关的tmux设置
代理桥 WebSocket守护进程+MCP插件 克劳德代码<->Codex
tmux桥mcp (this) 独立MCP服务器+直接tmux 任何代理,tmux之外零deps

smux vs tmux桥接mcp

尺寸 smux tmux桥接mcp(此)
🔌 代理如何连接 代理运行bash命令(tmux-bridge read/type/keys) 代理使用MCP工具调用(tmux_read/tmux_type/tmux_keys)
🚀 代理入职 安装技巧或注入系统提示来教bash命令 添加MCP配置JSON——代理自动发现9个工具
📦 先决条件 curl | bash 安装tmux+tmux.conf+CLI脚本 只需tmux+Node.js, npx 奔跑
⚙️ tmux配置 提供完整的tmux.conf(键绑定、鼠标、状态栏) 不接触tmux.conf——没有配置冲突
🛡️ 阅读防护 Bash CLI层(/tmp 文件锁) MCP服务器层(/tmp 文件锁,概念相同)
💻 语言 Bash(~300 LOC) TypeScript(~600 LOC)
📥 安装 curl | bash,写信给 ~/.smux/ npm install -g 或 npx
🤝 代理兼容性 任何可以运行bash的代理(需要技能/提示) 任何支持MCP的代理(标准协议)

👉 何时使用smux: 您需要一个完整的tmux设置(键绑定、鼠标支持、状态栏),您的代理支持技能系统,或者您可以轻松地注入系统提示。

👉 何时使用tmux桥mcp: 您想要一个即插即用的MCP服务器,它可以与任何兼容MCP的代理开箱即用,而无需接触您的tmux配置。

tmux桥(/tmb)vs克劳德代码本地(子代理+ /codex + /gemini)

维度 tmux桥 Claude代码原生
上下文隔离 每个窗格都有自己的完整对话上下文,在交互中持续存在 子代理每次都会生成新的对话上下文,结束时就会消失
坚持 窗格保持活动状态,累积对话历史记录 即发即弃,下次必须重新提供上下文
平行结构 真正独立的进程,无干扰 代理工具可以并行化,但共享计费/费率限制
模型多样性 每个窗格都可以运行不同的CLI(Codex、Gemini、Kimi) /codex /gemini 也可以做到这一点——这不是真正的差异化因素
通信开销 通过tmux读取/发送,有延迟,消息可能被截断 本机工具调用,结构化返回,高可靠性
结果集成 您必须手动读取窗格输出、解析和合成 子代理直接返回结构化结果,随时可用
操作复杂性 额外的tmux管理层(标签、窗格ID) 一次工具调用,完成
成本 每个窗格独立消耗自己的令牌预算 子代理共享同一会话的令牌池

裁决

tmux-bridge的真正优势归结为一件事: 持久上下文如果你需要一个能够记住最后30轮对话并继续跟进同一任务的代理,tmux窗格可以做到这一点,而子代理则不能。

但对于大多数任务,原生更好:

  • 通信更可靠(无tmux缓冲区截断)
  • 结果是结构化的——不需要解析终端输出
  • 操作更简单,少了一层抽象

实践指导:

  • 短期、一次性任务 → 本地子代理/ /codex / /gemini
  • 需要累积上下文的长时间运行的会话 (例如,审阅者持续关注同一PR)→ tmux网桥增加了真正的价值
  • 多窗格多角色布局只有在每个角色真正需要交叉对话状态时才有回报,否则开销将超过收益

📄 许可证

麻省理工学院