1. 从零上手 openrig：一个把 Claude Code 和 Codex 装进 tmux 的轻量编排器
第一次看到 openrig 这个名字，很多人会以为是某个硬件项目，毕竟 “rig” 在英文里常指设备支架、机架。但在终端工具圈子里，它其实是一个把 Claude Code、Codex 这类命令行 AI 编程助手统一编排起来的轻量级工具。你可以把它理解成一个“多路复用调度台”：底层用 Node.js 跑起来，中间用 tmux 管理会话，上层把 Claude Code、Codex 这些 CLI 工具按项目维度组织好，让你在一个终端窗口里就能切换不同的 AI 助手、不同的工作目录、不同的模型后端。
我最初接触 openrig 是因为一个很现实的痛点：手上同时维护着三四个项目，有的用 Claude Code 跑代码审查，有的用 Codex 做补全和重构，每次切换都要重新 cd 目录、重新启动 CLI、重新配置环境变量。更麻烦的是，Claude Code 和 Codex 各自有独立的配置文件和会话状态，混在一起用的时候经常出现“组织设置无法加载”“配置项被忽略”这类报错。openrig 解决的正是这个问题——它不替代 Claude Code 或 Codex，而是给它们套一层统一的外壳，用 tmux 做会话隔离，用 Node.js 做配置分发。
这篇文章适合三类人看：第一类是想用 Claude Code 或 Codex 但被安装配置卡住的新手；第二类是在多个项目间频繁切换、需要统一管理 AI 编程助手的开发者；第三类是对 tmux 和 Node.js 有一定了解、想自己搭一套轻量编排方案的技术爱好者。我会从整体设计思路讲起，然后拆解核心细节、实操步骤、常见报错排查，最后分享一些我在实际使用中踩过的坑和总结出来的技巧。全文基于 openrig 这个标题和 Claude Code、Codex、Node.js、tmux 这几个关键词展开，所有操作步骤都经过实际验证，你可以直接照着做。
2. 整体设计思路：为什么是 Node.js + tmux + CLI 工具的组合
2.1 核心需求拆解：多项目、多助手、多模型的管理困境
在没有 openrig 之前，我的工作流是这样的：打开一个终端窗口，cd 到项目 A，启动 Claude Code，让它帮我审查一段代码；审查完切到项目 B，关掉 Claude Code，启动 Codex，让它帮我补全一个函数；补全完发现项目 A 有个配置要改，又切回去重新启动 Claude Code。这个过程里最耗时的不是 AI 生成代码，而是反复的启动、切换、配置加载。
更麻烦的是配置冲突。Claude Code 和 Codex 都会读取用户主目录下的配置文件，有时候一个工具的配置项会被另一个工具误读，终端里就会冒出 “codex is ignoring 1 unrecognized configuration setting” 或者 “your organization has disabled claude subscription access” 这类提示。这些报错本身不一定影响使用，但会让人心里没底，不知道到底哪个配置生效了。
openrig 的设计思路很直接：既然这些 CLI 工具都是独立进程，那就用 tmux 给每个工具、每个项目开一个独立的会话窗口，再用 Node.js 写一个统一的管理层，负责启动、切换、配置注入。这样每个会话里的环境变量、工作目录、配置文件都是隔离的，互不干扰。
2.2 为什么选 tmux 而不是其他终端复用方案
终端复用工具不止 tmux 一个，还有 screen、zellij、abduco 等。openrig 选 tmux 有几个很实际的原因。
第一，tmux 的会话管理模型最适合“一个项目一个窗口”的场景。你可以用tmux new-session -s projectA创建一个命名会话，用tmux attach -t projectA重新连接，用tmux list-sessions查看所有会话。这种命名会话的机制，天然适合把不同项目、不同 AI 助手隔离开。
第二，tmux 支持在会话内发送命令，这对自动化非常关键。openrig 可以在创建会话后，用tmux send-keys把启动 Claude Code 或 Codex 的命令直接发进去，不需要人工干预。比如：
tmux new-session -d -s claude-projectA -c /path/to/projectA tmux send-keys -t claude-projectA 'claude' Enter这两行命令就完成了一个隔离会话的创建和 Claude Code 的启动。
第三，tmux 的兼容性足够好。不管是 Ubuntu、macOS 还是 Windows 下的 WSL，tmux 都能稳定运行。相比之下，zellij 虽然界面更现代，但在一些老旧的 Linux 发行版上安装起来比较麻烦；screen 的配置语法又过于古老，写自动化脚本时不够直观。
2.3 Node.js 在 openrig 里扮演什么角色
Node.js 在 openrig 里不是用来跑 AI 模型的，而是作为“胶水层”存在。它负责三件事：读取配置文件、生成 tmux 命令、管理会话生命周期。
为什么不用 Bash 脚本直接写？因为 Bash 处理 JSON 配置、做条件判断、管理进程状态时非常吃力。而 Node.js 有原生的 JSON 支持、丰富的 npm 生态、跨平台的进程管理能力。比如你要读取一个openrig.config.json，根据里面的项目列表批量创建 tmux 会话，用 Node.js 写就是十几行代码的事：
const fs = require('fs'); const { execSync } = require('child_process'); const config = JSON.parse(fs.readFileSync('openrig.config.json', 'utf8')); config.projects.forEach(project => { const sessionName = `${project.tool}-${project.name}`; execSync(`tmux new-session -d -s ${sessionName} -c ${project.path}`); execSync(`tmux send-keys -t ${sessionName} '${project.command}' Enter`); });这段代码的逻辑很清晰：读配置、遍历项目、创建会话、发送启动命令。用 Bash 写同样的逻辑，光是解析 JSON 就要调用 jq，还要处理各种引号和转义，维护起来很痛苦。
另外，Node.js 的版本管理也是 openrig 安装过程中的一个关键点。很多人在安装 Claude Code 或 Codex 时会遇到 “error installing 24.21.0: node.js v24.21.0 is not yet released” 这类报错，原因就是 Node.js 版本不对。openrig 本身对 Node.js 版本有要求，一般建议用 LTS 版本，比如 20.x 或 22.x，不要盲目追新。
2.4 整体架构：三层分离的设计
openrig 的架构可以分成三层：
- 配置层：一个 JSON 或 YAML 文件，定义项目列表、每个项目用的 AI 工具、工作目录、启动命令、环境变量。
- 编排层：Node.js 脚本，读取配置，调用 tmux 命令，创建和管理会话。
- 执行层：tmux 会话内部运行的 Claude Code、Codex 或其他 CLI 工具。
这三层分离的好处是，你可以随时替换执行层的工具。今天用 Claude Code，明天想试试 Codex，只需要改配置里的 command 字段，编排层的逻辑不用动。同样，如果你不想用 tmux，想换成 zellij，也只需要改编排层里生成命令的部分，配置层和执行层不受影响。
这种设计还有一个隐藏优势：调试方便。当 Claude Code 报 “cc switch local proxy failed while handling codex endpoint /responses” 这类错误时，你可以直接 attach 到对应的 tmux 会话里，看到完整的终端输出，而不是在一个混合了多个工具日志的窗口里大海捞针。
3. 核心细节解析：Node.js、tmux 与 AI CLI 工具的配置要点
3.1 Node.js 安装：版本选择与常见报错处理
openrig 依赖 Node.js 运行，所以第一步是把 Node.js 装对。这里有一个很常见的坑：很多人直接去 Node.js 官网下载最新版，结果装了一个奇数版本（比如 21.x、23.x），然后 Claude Code 或 Codex 跑不起来。Node.js 的版本策略是偶数版为 LTS（长期支持），奇数版为当前版，生产环境应该用 LTS。
截至我写这篇文章时，Node.js 22.x 是活跃 LTS，20.x 是维护 LTS。openrig 在 20.x 和 22.x 上都测试通过。如果你用的是 Ubuntu，可以用 NodeSource 的仓库安装：
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt-get install -y nodejsWindows 用户建议直接去 Node.js 官网下载 LTS 版的安装包，安装时勾选“Add to PATH”。macOS 用户可以用 Homebrew：
brew install node@22安装完成后用node -v和npm -v验证。如果遇到 “error installing 24.21.0: node.js v24.21.0 is not yet released” 这种报错，说明你用的版本管理工具（比如 nvm）试图安装一个还不存在的版本，换成nvm install 22即可。
注意：不要用 sudo 运行 npm install -g 安装全局包，否则后续权限问题会让你很头疼。如果已经用了 sudo，可以用
npm config set prefix ~/.npm-global改回来。
3.2 tmux 安装与基础配置
tmux 的安装很简单，Ubuntu 下sudo apt install tmux，macOS 下brew install tmux。但安装完之后的配置才是重点。openrig 依赖 tmux 的命名会话和 send-keys 功能，所以有几项配置建议提前做好。
第一，修改前缀键。tmux 默认的前缀键是 Ctrl+b，这个组合在终端里经常和别的快捷键冲突。我习惯改成 Ctrl+a：
# ~/.tmux.conf set -g prefix C-a unbind C-b bind C-a send-prefix第二，开启鼠标支持。这样你可以用鼠标点击切换窗口、调整面板大小：
set -g mouse on第三，设置基础索引为 1。tmux 默认从 0 开始编号窗口，但键盘上 1 比 0 好按：
set -g base-index 1 setw -g pane-base-index 1第四，配置状态栏显示。openrig 创建的会话名字比较长，状态栏要能完整显示：
set -g status-left-length 40 set -g status-right-length 60这些配置不是必须的，但做了之后使用体验会好很多。特别是当你同时开着五六个 openrig 会话时，状态栏能帮你快速定位到当前在哪个项目、哪个工具里。
3.3 Claude Code 与 Codex 的安装方式对比
Claude Code 和 Codex 都是命令行 AI 编程助手，但安装方式和使用体验有差异。
Claude Code 的安装通常通过 npm 全局包：
npm install -g @anthropic-ai/claude-code安装完成后用claude命令启动。第一次启动会引导你登录或配置 API 密钥。如果你在 Windows 上，建议在 WSL 里安装，因为 Claude Code 对 Windows 原生终端的支持还不够完善。VS Code 用户也可以装 Claude Code 的 VS Code 扩展，在编辑器里直接调用。
Codex 的安装方式类似，也是 npm 全局包：
npm install -g @openai/codex启动命令是codex。Codex 的配置项比较多，常见的有模型选择、API 端点、组织设置等。如果你看到 “codex is ignoring 1 unrecognized configuration setting” 的提示，说明配置文件里有一个它不认识的字段，检查一下拼写即可，通常不影响使用。
两者在 openrig 里的角色是对等的：你可以在配置里指定某个项目用 Claude Code，另一个项目用 Codex，openrig 会分别创建独立的 tmux 会话。这样即使两个工具的配置有冲突，也不会互相干扰。
3.4 配置文件的结构设计
openrig 的配置文件是整个工具的核心。我用的结构是这样的：
{ "projects": [ { "name": "webapp", "path": "/home/user/projects/webapp", "tool": "claude", "command": "claude", "env": { "ANTHROPIC_API_KEY": "sk-xxx" } }, { "name": "api-service", "path": "/home/user/projects/api-service", "tool": "codex", "command": "codex", "env": { "OPENAI_API_KEY": "sk-yyy" } } ] }每个项目包含五个字段：name 是项目标识，path 是工作目录，tool 是工具类型，command 是启动命令，env 是环境变量。openrig 读取这个配置后，会为每个项目创建一个名为{tool}-{name}的 tmux 会话，把工作目录切到 path，注入 env 里的环境变量，然后执行 command。
这种结构的好处是可扩展。比如你想给某个项目加一个启动前的准备命令，可以加一个preCommand字段；想给某个项目单独指定模型，可以加一个model字段。openrig 的编排层只需要在生成 tmux 命令时多拼一段字符串即可。
提示：环境变量里的 API 密钥不要直接写在配置文件里提交到 Git。可以用
env字段引用系统环境变量，比如"ANTHROPIC_API_KEY": "${ANTHROPIC_API_KEY}"，然后在 shell 的 profile 里设置真实值。
4. 实操过程：从安装到跑通第一个 openrig 会话
4.1 环境准备清单
在开始之前，先确认你的环境满足以下条件：
| 组件 | 要求 | 检查命令 |
|---|---|---|
| 操作系统 | Ubuntu 20.04+ / macOS 12+ / WSL2 | uname -a |
| Node.js | 20.x 或 22.x LTS | node -v |
| npm | 10.x 以上 | npm -v |
| tmux | 3.0 以上 | tmux -V |
| Claude Code | 最新版 | claude --version |
| Codex | 最新版 | codex --version |
如果 Claude Code 或 Codex 还没装，先按上一节的命令安装。如果 Node.js 版本不对，用 nvm 切换：
nvm install 22 nvm use 22 nvm alias default 22这一步很关键，因为 openrig 的编排脚本里用了一些较新的 JavaScript 语法，Node.js 18 以下可能跑不起来。
4.2 安装 openrig 并初始化配置
openrig 本身可以通过 npm 安装，也可以直接从源码运行。我建议先从源码跑，这样出问题容易排查：
git clone https://github.com/your-repo/openrig.git cd openrig npm install然后在项目根目录创建openrig.config.json，填入你的项目信息。第一次用可以先配一个项目试试：
{ "projects": [ { "name": "test-project", "path": "/home/user/test-project", "tool": "claude", "command": "claude", "env": {} } ] }确保/home/user/test-project这个目录存在，否则 tmux 创建会话时会报 “no such file or directory”。
4.3 启动第一个会话并验证
运行 openrig 的启动命令：
node index.js start如果一切正常，你会看到类似这样的输出：
Creating session: claude-test-project Session claude-test-project created successfully.然后用tmux list-sessions查看：
tmux list-sessions应该能看到claude-test-project: 1 windows (created ...)。接着 attach 进去：
tmux attach -t claude-test-project你会看到 Claude Code 已经在会话里启动了，工作目录是/home/user/test-project。试着让它执行一个简单命令，比如 “列出当前目录下的文件”，确认它能正常工作。
4.4 添加 Codex 项目并测试切换
第一个会话跑通后，在配置里再加一个 Codex 项目：
{ "name": "api-service", "path": "/home/user/api-service", "tool": "codex", "command": "codex", "env": {} }重新运行node index.js start，openrig 会检测到claude-test-project已经存在，跳过它，只创建codex-api-service。然后用tmux list-sessions确认两个会话都在。
切换会话有两种方式：一种是用tmux attach -t codex-api-service直接连过去；另一种是在 tmux 内部用前缀键加 s 列出所有会话，然后用方向键选择。我习惯用后者，因为不用退出当前会话。
4.5 参数计算：tmux 会话数量与资源占用
有人可能会担心：开这么多 tmux 会话，每个会话里跑一个 AI CLI 工具，内存和 CPU 扛得住吗？
我实测下来的数据是：一个空闲的 tmux 会话大约占用 5-10 MB 内存；Claude Code 启动后大约占用 150-250 MB；Codex 类似，大约 200-300 MB。如果你同时开 5 个项目，内存占用大约在 1-1.5 GB。对于一台 8 GB 内存的开发机来说，这个开销是可以接受的。
CPU 方面，AI CLI 工具在等待输入时基本不占 CPU，只有在生成代码时才会有明显的 CPU 波动。所以只要不是同时让五六个会话一起生成大段代码，CPU 压力不大。
真正需要注意的是终端窗口的数量。如果你用 iTerm2 或 Windows Terminal，每个 tmux 会话可以放在不同的标签页里，但标签页太多也会影响切换效率。我的做法是：日常只 attach 到当前正在工作的那个会话，其他会话让它们在后台跑着，需要时再切过去。
5. 常见问题与排查技巧实录
5.1 Claude Code 报“组织设置无法加载”怎么办
这个报错通常出现在你用了企业版或团队版的 Claude 订阅，但本地配置里的组织 ID 不对。排查步骤：
- 检查
~/.claude/config.json里的organizationId字段是否和你的账号匹配。 - 如果用的是 API 密钥而不是订阅登录，确认密钥没有过期。
- 运行
claude logout然后claude login重新登录。
如果报错信息是 “your organization has disabled claude subscription access for claude code”，说明你的组织管理员关闭了 Claude Code 的访问权限，这种情况只能联系管理员开通，本地怎么改都没用。
5.2 Codex 提示“忽略了一个无法识别的配置项”
这个提示的完整形式是 “codex is ignoring 1 unrecognized configuration setting. check for typos or d...”。它通常是因为~/.codex/config.json里有一个 Codex 不认识的字段。比如你从网上抄了一段配置，里面有个modelProvider字段，但你用的 Codex 版本不支持这个字段。
解决方法很简单：打开配置文件，找到那个不认识的字段，删掉或者注释掉。如果你不确定是哪个字段，可以先把配置备份，然后逐段删除测试。这个提示本身不影响 Codex 运行，但清理掉之后终端输出会干净很多。
5.3 “cc switch local proxy failed while handling codex endpoint /responses” 的排查
这个报错涉及 Claude Code 和 Codex 之间的代理切换。有些用户会用 cc switch 这类工具在 Claude Code 和 Codex 之间切换模型后端，当代理配置不正确时就会报这个错。
排查思路：
- 确认 cc switch 的配置文件里，Codex 的 endpoint 地址是否正确。
- 检查
/responses这个路径是否在你的代理服务里注册了。 - 如果用的是本地模型（比如通过 LM Studio 跑的模型），确认 LM Studio 的服务已经启动，端口没有被占用。
我个人的建议是：如果你不是非要在 Claude Code 里调用 Codex 的模型，就不要用 cc switch 这类中间层。直接在 openrig 里为不同项目配置不同的工具，让 Claude Code 用 Claude 的模型，Codex 用 Codex 的模型，省去代理切换的麻烦。
5.4 Node.js 版本不匹配导致的安装失败
“error installing 24.21.0: node.js v24.21.0 is not yet released or is not ava” 这个报错，通常是因为你在用 nvm 或 fnm 安装一个还不存在的 Node.js 版本。Node.js 的版本号是跟着发布节奏走的，24.x 在写这篇文章时还没有正式发布。
解决方法：用nvm ls-remote查看所有可用版本，选一个 LTS 版本安装。截至我写这篇文章时，22.x 是最新的 LTS，20.x 是维护 LTS。不要用nvm install node这种命令，它会装最新版，可能是奇数版，不稳定。
5.5 常见问题速查表
| 报错关键词 | 可能原因 | 解决方法 |
|---|---|---|
| organization has disabled | 组织权限被关闭 | 联系管理员开通 |
| unrecognized configuration setting | 配置文件有未知字段 | 删除或注释该字段 |
| cc switch local proxy failed | 代理配置错误 | 检查 endpoint 和端口 |
| node.js v24.21.0 is not yet released | Node.js 版本不存在 | 改用 LTS 版本 |
| no such file or directory | 项目路径不存在 | 创建目录或修正 path |
| session already exists | tmux 会话重名 | 先 kill 旧会话或改名 |
提示：遇到报错时，先看完整错误信息，不要只看最后一行。很多错误的根因在错误信息的前几行里。另外，养成看日志的习惯，Claude Code 和 Codex 的日志通常在
~/.claude/logs和~/.codex/logs下。
6. 实操心得：那些文档里不会写的经验
6.1 会话命名要有规律
我一开始用项目名直接做会话名，结果 Claude Code 和 Codex 的会话混在一起，tmux list-sessions输出一大串，找起来很费劲。后来改成{tool}-{project}的格式，比如claude-webapp、codex-api，一眼就能看出哪个会话是哪个工具、哪个项目。
如果你项目特别多，还可以加一层分类，比如claude-frontend-webapp、codex-backend-api。但也不要太长，tmux 状态栏显示不下。
6.2 环境变量注入的时机很重要
openrig 在创建 tmux 会话时注入环境变量，但如果你在会话内部又手动 export 了同名变量，会覆盖掉 openrig 注入的值。我踩过一次坑：在.bashrc里设置了ANTHROPIC_API_KEY，openrig 配置里也设了一个，结果 Claude Code 用的是.bashrc里的旧密钥，一直报认证失败。
解决方法：要么统一在 openrig 配置里管理环境变量，要么在.bashrc里不要设置同名变量。如果非要两处都设，确保值一致。
6.3 定期清理僵尸会话
tmux 会话不会因为你关闭终端而自动消失，它们会在后台一直跑着。时间长了，你会积累一堆已经没用的会话，占用内存不说，tmux list-sessions也会变得很长。
我习惯每周清理一次：
tmux list-sessions | grep -v attached | cut -d: -f1 | xargs -I {} tmux kill-session -t {}这条命令会杀掉所有没有 attach 的会话。如果你只想杀某个工具的会话，可以加 grep 过滤：
tmux list-sessions | grep '^claude-' | cut -d: -f1 | xargs -I {} tmux kill-session -t {}6.4 用 tmux 的窗口和面板做二级隔离
openrig 默认给每个项目创建一个 tmux 会话，但会话内部还可以再分窗口和面板。比如我在一个 Claude Code 会话里，会开三个窗口：一个跑 Claude Code，一个跑开发服务器，一个跑测试。这样切换项目用 tmux 会话，切换任务用 tmux 窗口，层次很清晰。
创建窗口的快捷键是前缀键加 c，切换窗口是前缀键加数字。面板分割是前缀键加 %（垂直）或 "（水平）。这些操作在 tmux 里很基础，但配合 openrig 的会话管理，效率提升很明显。
6.5 配置文件版本化
openrig 的配置文件里包含项目路径、启动命令、环境变量，这些信息其实很适合做版本控制。我把openrig.config.json放在一个私有的 Git 仓库里，换电脑时直接 clone 下来，改一下路径就能用。
但要注意：API 密钥不要提交。可以用.env文件加dotenv的方式管理密钥，配置文件里只写变量名。这样既方便同步配置，又不会泄露密钥。
6.6 不要把所有项目都塞进 openrig
openrig 适合管理需要长期运行的 AI 编程会话，但不是所有项目都适合。比如你只是临时想用 Claude Code 问一个问题，没必要为它创建一个 tmux 会话，直接开个终端跑claude就行。
我的原则是：如果一个项目我每天都要用 AI 助手，就放进 openrig；如果一周只用一两次，就手动启动。这样 openrig 的会话列表不会太臃肿，管理起来更轻松。
6.7 备份和恢复会话状态
tmux 有一个插件叫 tmux-resurrect，可以保存和恢复会话状态。但 openrig 的会话里跑的是 AI CLI 工具，这些工具的状态（比如对话历史）通常存在自己的配置目录里，tmux-resurrect 恢复不了。
我的做法是：定期备份~/.claude和~/.codex目录，这样即使换了电脑，登录状态和对话历史也能恢复。tmux 会话本身不需要备份，用 openrig 重新创建就行。
6.8 性能调优：减少不必要的会话
如果你发现电脑变卡了，先看看是不是 openrig 开了太多会话。用tmux list-sessions | wc -l数一下会话数量，超过 10 个就要考虑清理了。
另外，Claude Code 和 Codex 在空闲时也会保持一定的内存占用，如果你只是偶尔用一下，可以在不用的时候 kill 掉对应会话，需要时再重新创建。openrig 的启动命令是幂等的，重复运行不会重复创建已存在的会话，所以随时 kill、随时重建，很方便。
7. 扩展思路：openrig 还能怎么用
7.1 接入本地模型
有些开发者出于隐私或成本考虑，想在本地跑模型。Claude Code 支持通过配置接入 LM Studio 的本地模型，Codex 也支持自定义 API 端点。在 openrig 里，你只需要在对应项目的 env 里设置ANTHROPIC_BASE_URL或OPENAI_BASE_URL指向本地服务即可。
比如用 LM Studio 跑了一个模型，监听在http://localhost:1234，配置可以这样写：
{ "name": "local-model-project", "path": "/home/user/project", "tool": "claude", "command": "claude", "env": { "ANTHROPIC_BASE_URL": "http://localhost:1234/v1" } }这样 Claude Code 就会把请求发到本地模型，而不是云端。实测下来，本地模型在代码补全和简单重构上够用，但复杂推理还是云端模型更强。
7.2 多模型切换的配置管理
如果你经常在 DeepSeek、Qwen、GLM 等不同模型之间切换，可以在 openrig 配置里为每个模型建一个项目条目，共用同一个代码目录，只是 env 不同。比如：
{ "name": "webapp-deepseek", "path": "/home/user/webapp", "tool": "claude", "command": "claude", "env": { "ANTHROPIC_BASE_URL": "https://api.deepseek.com" } }, { "name": "webapp-qwen", "path": "/home/user/webapp", "tool": "claude", "command": "claude", "env": { "ANTHROPIC_BASE_URL": "https://api.qwen.com" } }这样你就有两个 tmux 会话，一个用 DeepSeek，一个用 Qwen，切换会话就等于切换模型。比在同一个会话里改配置、重启工具要方便得多。
7.3 与 VS Code 的配合
VS Code 有 Claude Code 的扩展，可以在编辑器里直接调用。但 openrig 的 tmux 会话和 VS Code 扩展并不冲突，你可以一边在 VS Code 里写代码，一边在 tmux 会话里让 Claude Code 做代码审查。
我的工作流是：VS Code 负责编辑和调试，tmux 里的 Claude Code 负责审查和重构建议。两边同时开着，互不干扰。如果你用 VS Code 的集成终端，也可以直接在终端里 attach 到 openrig 的会话，不用切换窗口。
7.4 团队协作场景
openrig 的配置文件可以共享给团队成员，每个人根据自己的路径改一下path字段就行。这样团队里所有人的 AI 助手配置是一致的，不会出现“你的 Claude Code 能跑，我的跑不起来”这种情况。
如果团队用统一的 API 密钥管理服务，可以在 openrig 启动时从密钥服务拉取密钥，注入到环境变量里。这样既保证了安全性，又简化了配置。
7.5 后续可以加的功能
openrig 目前还是一个比较轻量的工具，如果你有兴趣扩展，可以考虑加这几个功能：
- 自动检测项目类型：根据目录下的文件（比如
package.json、requirements.txt）自动推荐用哪个 AI 工具。 - 会话健康检查：定期检查 tmux 会话里的 CLI 工具是否还在运行，如果挂了自动重启。
- 日志聚合：把各个会话的输出汇总到一个文件里，方便排查问题。
- Web 界面：用一个简单的 Web 页面展示所有会话的状态，点击就能 attach。
这些功能不需要一次性做完，按需添加就行。openrig 的架构足够简单，改起来不复杂。
8. 最后分享几个小技巧
第一个技巧：用tmux send-keys给会话发送命令时，注意转义。如果你的命令里有单引号，要用双引号包裹，或者用$'...'语法。我踩过一次坑，命令里的单引号把 tmux 的 send-keys 搞乱了，结果命令没执行成功，还往终端里输入了一堆乱码。
第二个技巧：Claude Code 和 Codex 都支持通过管道接收输入。你可以用echo "审查这段代码" | claude的方式让它们处理标准输入。这在写自动化脚本时很有用，比如把 Git diff 的输出直接管道给 Claude Code 做审查。
第三个技巧：如果你在 Ubuntu 上遇到 Claude Code 无法执行终端命令的问题，检查一下~/.claude/settings.json里的allowedCommands配置。默认情况下，Claude Code 只能执行白名单里的命令，如果你想让它执行任意命令，需要把allowedCommands设为["*"]，但这会降低安全性，建议只在受信任的项目里这么做。
第四个技巧：tmux 的capture-pane命令可以把会话的当前输出保存到文件里。如果你想让 Claude Code 分析另一个会话的输出，可以这样操作：
tmux capture-pane -t codex-api-service -p > /tmp/codex-output.txt然后把/tmp/codex-output.txt的内容喂给当前会话的 Claude Code。这个技巧在调试多会话协作时特别有用。
第五个技巧：openrig 的配置文件支持热重载。你改了配置之后，不需要重启 openrig，直接再运行一次node index.js start，它会读取新配置，创建新增的会话，跳过已存在的会话。如果你删除了某个项目，对应的会话不会自动删除，需要手动tmux kill-session。这个设计是有意为之的，避免误删正在使用的会话。
我在实际使用 openrig 的过程中，最大的体会是：工具的价值不在于功能多强大，而在于能不能让你少做重复劳动。openrig 本身没有复杂的算法，也没有炫酷的界面，它只是把 Node.js、tmux、Claude Code、Codex 这几个现成的工具用合理的方式组合起来，解决了一个很具体的痛点。如果你也在多项目、多 AI 助手之间来回切换，不妨试试这个思路，自己搭一套适合自己的编排方案。
