Tmux Bridge

tmux桥mcp

英语 | 简体中文

tmux-bridge-mcp

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

🖥️ 什么是tmux？

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

What is 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中发生了什么。

The Problem

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

The Solution

⚡ 你可以用tmux桥做什么？

安装后，您的AI代理可以：

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

🤖 支持的代理

Supported Agents

测试并记录

应该有效（任何MCP兼容的代理）

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

💡 为什么

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

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

使用案例：

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

您需要什么：

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

😩 无tmux网桥

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

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

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

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

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

🚀 快速开始

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

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

npx tmux-bridge-mcp setup

此功能会自动检测您计算机上的Claude Code、Gemini CLI、Codex和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 一旦获取了最新信息，您的代理将在下次启动时使用它。

🏗️ 运作原理

Layered Architecture

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      |            +--------------+
                             +---------------+

Architecture

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

Read-Act-Read Workflow

读取保护在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"]
    }
  }
}

化学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"

Kimi CLI Bridging

🔧 工具参考

目标可以是窗格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网桥是为 单机上的本地开发。它假设所有连接的MCP代理都是可信的：

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

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

📝 系统指令

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

🔗 相关项目

smux vs tmux桥接mcp

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

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

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

裁决

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

但对于大多数任务，原生更好：

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

实践指导：

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

📄 许可证

麻省理工学院