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 下的 WSLtmux 都能稳定运行。相比之下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 是活跃 LTS20.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 用户可以用 Homebrewbrew install node22安装完成后用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 tmuxmacOS 下brew install tmux。但安装完之后的配置才是重点。openrig 依赖 tmux 的命名会话和 send-keys 功能所以有几项配置建议提前做好。第一修改前缀键。tmux 默认的前缀键是 Ctrlb这个组合在终端里经常和别的快捷键冲突。我习惯改成 Ctrla# ~/.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另一个项目用 Codexopenrig 会分别创建独立的 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 / WSL2uname -aNode.js20.x 或 22.x LTSnode -vnpm10.x 以上npm -vtmux3.0 以上tmux -VClaude Code最新版claude --versionCodex最新版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 startopenrig 会检测到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 MBCodex 类似大约 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 是最新的 LTS20.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 releasedNode.js 版本不存在改用 LTS 版本no such file or directory项目路径不存在创建目录或修正 pathsession already existstmux 会话重名先 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_KEYopenrig 配置里也设了一个结果 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 不要把所有项目都塞进 openrigopenrig 适合管理需要长期运行的 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 助手之间来回切换不妨试试这个思路自己搭一套适合自己的编排方案。