openrig:用Node.js与tmux编排Claude Code和Codex终端AI编码工作台
1. 从“openrig”说起一个把终端AI编码工具串起来的脚手架第一次看到“openrig”这个词我脑子里蹦出来的不是某个具体软件而是一类东西——把散落在终端里的 AI 编码工具统一编排起来的工作台。你如果最近在折腾 Claude Code、Codex CLI 这类命令行 AI 助手大概率会有同感单个工具用起来都挺香但一旦要在同一台机器上同时跑好几个、还要切换模型、还要管理会话、还要让它们各自待在自己的终端窗口里互不打架事情就开始变得琐碎。openrig 要解决的正是这种“工具都装好了但用起来还是乱”的问题。我先把话说在前面openrig 不是一个官方大厂产品它更像是一个围绕Node.js 运行时 tmux 会话管理 Claude Code / Codex 等 CLI 工具组合出来的个人级编排方案。它的核心价值不在于发明了什么新算法而在于把几个成熟组件用一套清晰的约定粘在一起让你在一台机器本地或远程上能稳定地拉起多个 AI 编码会话并且随时切换、随时接管。适合谁来参考三类人一是刚装完 Claude Code 或 Codex、还在纠结怎么在 Windows / Ubuntu / VS Code 之间打通的人二是想让多个 AI 助手并行干活、又不想开一堆窗口手动管理的人三是喜欢在终端里干活、对 tmux 和 Node.js 不陌生、愿意自己动手搭一套工作流的开发者。关键词里那一串热搜词其实已经把痛点暴露得很清楚了claude code安装、codex安装、node.js安装、tmux、cc switch local proxy failed、codex is ignoring 1 unrecognized configuration setting……这些全是“装完之后怎么用顺”的问题。openrig 这类脚手架的意义就是把这些零散的坑一次性收拢到一个可复现的结构里。下面我按自己实际搭这套东西的顺序把设计思路、核心细节、实操过程和踩坑记录完整拆一遍。2. 整体设计思路为什么是 Node.js tmux CLI 工具这套组合2.1 先想清楚要解决的核心矛盾在动手之前我习惯先把矛盾列出来。用终端 AI 编码工具的人通常会撞上这么几堵墙会话易失Claude Code 或 Codex 跑在一个终端里你 SSH 一断、窗口一关上下文就没了长任务直接白跑。多工具冲突Claude Code 和 Codex 各自有自己的配置目录、环境变量、API 端点混在一起容易互相污染。模型切换麻烦今天想用云端模型明天想接本地 LM Studio后天想换第三方 API每次改配置都像拆炸弹。跨平台差异Windows 上装 Node.js 和 Ubuntu 上装完全是两套体验VS Code 里再嵌一层又是另一回事。openrig 这类方案的设计出发点就是把这四堵墙一次性绕过去。它的思路不是“写一个大而全的程序”而是“用最小的粘合层把已经好用的东西组合起来”。2.2 为什么选 Node.js 作为运行时底座Claude Code 和 Codex CLI 这两个工具本质上都是Node.js 生态里的命令行程序。你搜node.js是干什么的、node.js安装、node.js lts下载这些词说明很多人第一步就卡在运行时上。选 Node.js 作为底座不是偏好问题而是被动选择——这些 CLI 工具本身就依赖它。这里有个关键决策点用 LTS 还是追最新版。热搜里有一条error installing 24.21.0: node.js v24.21.0 is not yet released or is not ava这就是典型的“版本号写错或追新翻车”。我的经验是装 Node.js 一律优先 LTS 版本通过官方渠道下载别去追那些还没正式发布的版本号。原因很简单AI CLI 工具对 Node.js 的版本兼容性通常滞后于最新版你追新只会给自己找不兼容的麻烦。提示安装 Node.js 时优先选择 LTS 长期支持版本安装完成后用node -v和npm -v双重确认避免出现命令存在但版本错乱的情况。2.3 为什么用 tmux 做会话层这是整套方案里我最想强调的一环。很多人第一次听说tmux会问我直接开终端不行吗行但只适合短任务。tmux 的价值在于把“进程”和“窗口”解耦——你的 AI 会话跑在 tmux 的 session 里窗口关了、SSH 断了session 还在后台活着下次 attach 回去上下文原封不动。对 openrig 这种要同时管理多个 AI 会话的场景tmux 几乎是唯一合理的选择。你可以给每个工具开一个独立 session一个跑 Claude Code一个跑 Codex一个跑本地模型代理。它们互不干扰你用一个命令就能在它们之间跳来跳去。这比开一堆终端标签页优雅得多也比写复杂的进程管理脚本简单得多。2.4 为什么不做“大一统封装”我见过不少人一上来就想写个脚本把所有工具包成一个命令。我的建议是别这么干。Claude Code 和 Codex 都在快速迭代你今天封装的参数明天可能就变了。openrig 这类方案的正确姿势是薄封装只负责拉起会话、切换环境、管理配置目录具体工具怎么用还是交给工具自己。这样工具升级了你的脚手架不用跟着大改。3. 核心细节解析环境、配置与工具链的实操要点3.1 Node.js 安装跨平台差异与避坑Node.js 的安装看似简单但热搜里node.js官网下载openclaw、安装node.js、node.js lts下载这些词说明翻车的人不少。我按平台说清楚。Windows 平台直接去 Node.js 官网下载 LTS 的.msi安装包一路下一步即可。安装时注意勾选“Add to PATH”否则后面在终端里敲node会提示找不到命令。装完打开新的 PowerShell 或 CMD运行node -v验证。如果你用的是 VS Code 内置终端记得重启 VS Code否则它可能还拿着旧的环境变量。Ubuntu / Linux 平台不要用apt install nodejs直接装系统源里的版本往往太旧。推荐用 NodeSource 的仓库或者直接用官方二进制包。装完之后同样用node -v确认。这里有个细节如果你之前用 apt 装过旧版先卸干净再装否则会出现两个 node 打架的情况。版本管理如果你需要在多个 Node.js 版本之间切换比如某些工具要求特定版本可以用 nvm 这类版本管理器。但对大多数只跑 Claude Code / Codex 的人来说一个稳定的 LTS 就够了别给自己加复杂度。平台推荐安装方式验证命令常见坑Windows官网 LTS msi 包node -v忘记勾选 PATH终端找不到命令UbuntuNodeSource 仓库或官方二进制node -vapt 源版本过旧新旧版本冲突macOS官网 pkg 或 Homebrewnode -v权限问题导致全局包装不上3.2 Claude Code 与 Codex 的安装与配置隔离这两个工具是 openrig 的主角。热搜里claude code安装、codex安装、codex安装教程、claude code下载安装全是围绕安装的说明第一步就劝退了不少人。安装本身通常是通过 npm 全局安装命令形式类似npm install -g加包名。装完之后最关键的一步是配置隔离。Claude Code 和 Codex 各自会读取自己的配置目录和环境变量。如果你不做隔离两个工具可能读到同一份配置出现codex is ignoring 1 unrecognized configuration setting这种警告或者更糟——端点串了。我的做法是给每个工具准备独立的配置目录通过环境变量在启动时指定。比如启动 Claude Code 的会话里环境变量指向~/.config/claude-code启动 Codex 的会话里指向~/.config/codex。这样即使两个工具都读同名变量也不会互相污染。注意配置隔离要在会话级别做而不是全局改环境变量。全局改的后果是你在一个终端里切换工具时配置会互相覆盖排查起来非常痛苦。3.3 模型接入本地模型与第三方 API 的切换逻辑热搜里claude code 调用lmstudio的本地模型、codex接入deepseek、使用cc switch 接入 deepseek v4, qwen, glm等模型这些词指向的是同一个需求让 CLI 工具连到不同的模型后端。这里要理解一个概念Claude Code 和 Codex 这类工具本身是“客户端”它们通过一个兼容的 API 端点跟模型通信。你想接本地 LM Studio就把端点指向本地的服务地址想接第三方 API就把端点换成对应的地址同时配上对应的密钥。切换的本质就是换端点 换密钥 换模型名这三件事。cc switch local proxy failed while handling codex endpoint /responses这个报错我判断大概率是代理层在转发请求时端点路径或请求格式没对上。Codex 用的是/responses这类端点如果你中间加了一层代理代理没有正确透传路径和请求体就会失败。排查思路是先用最直接的方式不经过代理确认工具本身能连通再一层层加上代理定位是哪一层出的问题。3.4 tmux 会话管理命名、切换与持久化tmux 用起来不难但要用得顺手得建立一套命名约定。我的习惯是按工具和用途命名 session比如cc-main给 Claude Code 主会话codex-main给 Codexlocal-model给本地模型代理。这样你tmux ls一眼就能看清哪个是哪个。创建会话用tmux new -s 名字脱离用Ctrlb然后按d重新接入用tmux attach -t 名字。这几个操作熟练之后管理多个 AI 会话就跟切浏览器标签一样自然。有个细节值得说tmux 里的滚动和复制默认不太友好建议在配置文件里开启鼠标模式这样你可以直接用鼠标滚轮翻看 AI 输出的长内容。这个改动很小但体验提升明显。4. 实操过程从零搭起一套可复用的 AI 编码工作台4.1 第一步把运行时和工具装齐我按实际顺序走一遍。先确认 Node.js 装好node -v有输出。然后全局安装 Claude Code 和 Codex 对应的 npm 包。安装过程中如果遇到网络慢可以配置 npm 的镜像源加速这是常规操作。装完之后不要急着启动。先分别跑一下--version或--help确认两个工具都能正常响应。这一步能帮你把“装没装上”和“装上了但配置不对”两类问题分开。4.2 第二步建立配置目录结构我在用户主目录下建一个统一的工作目录比如~/ai-rig/里面按工具分子目录mkdir -p ~/ai-rig/claude-code mkdir -p ~/ai-rig/codex mkdir -p ~/ai-rig/logs每个子目录放对应工具的配置。日志目录单独留着方便出问题时翻记录。这个结构看起来简单但它让“配置在哪”这件事变得一目了然后面排查问题能省很多时间。4.3 第三步写一个拉起会话的脚本openrig 的核心其实就是几个拉起 tmux 会话的脚本。我写一个最简版本给你参考#!/bin/bash # 拉起 Claude Code 会话 tmux new-session -d -s cc-main tmux send-keys -t cc-main export CLAUDE_CONFIG_DIR~/ai-rig/claude-code C-m tmux send-keys -t cc-main claude C-m # 拉起 Codex 会话 tmux new-session -d -s codex-main tmux send-keys -t codex-main export CODEX_CONFIG_DIR~/ai-rig/codex C-m tmux send-keys -t codex-main codex C-m这段脚本做了三件事创建后台会话、设置该会话专属的配置目录环境变量、启动工具。-d表示后台创建不抢占当前终端。send-keys把命令“敲”进会话里C-m相当于回车。提示环境变量名要以工具实际读取的为准不同版本可能不同。写脚本前先查一下当前版本的文档或--help输出别照抄别人的变量名。4.4 第四步模型端点的配置与验证以接本地模型为例。假设你在本地跑了一个兼容 API 的服务监听在某个端口。你要做的是在工具的配置里把端点指向它。配置改完后先用一个最简单的请求验证连通性别一上来就跑复杂任务。验证的顺序我建议是先确认本地服务本身能响应用 curl 之类的工具直接打一下端点再确认工具能连上这个端点最后才跑实际编码任务。这样出问题时你能快速定位是服务的问题还是工具配置的问题。4.5 第五步日常使用与切换日常用起来就是几个动作tmux attach -t cc-main进 Claude Code 会话tmux attach -t codex-main进 Codex 会话Ctrlb d脱离。想同时看两个可以开两个终端窗口分别 attach或者用 tmux 的分屏功能。切换模型的时候我倾向于改配置后重启对应会话而不是在运行中的会话里热改。热改容易留下状态不一致的隐患重启虽然多花几秒但干净。5. 常见问题与排查技巧实录5.1 安装阶段的典型报错热搜里那些报错词我挑几个高频的说说排查思路。error installing 24.21.0: node.js v24.21.0 is not yet released or is not ava—— 这是版本号问题。要么是你指定的版本根本不存在要么是镜像源还没同步。解决办法是换成 LTS 版本号或者去掉版本号让它装默认的 LTS。your organization has disabled claude subscription access for claude code—— 这是账号权限层面的提示说明当前账号的订阅方式不支持这个工具。这种情况不是技术问题换用支持的方式即可具体以工具官方说明为准。note: claude code might not be available in your country—— 这是区域可用性提示。遇到这类提示按工具官方支持的范围来处理不要尝试绕过。5.2 配置阶段的典型报错codex is ignoring 1 unrecognized configuration setting. check for typos or d—— 这是配置项拼写错误或版本不匹配。Codex 在升级后可能改了配置项名称你旧配置里的某个键它不认识了。解决办法是对照当前版本文档把不认识的键删掉或改名。别忽略这个警告它往往意味着你的某项配置根本没生效。cc switch local proxy failed while handling codex endpoint /responses—— 前面提过这是代理转发问题。排查顺序绕过代理直连是否正常 → 代理是否透传了完整路径 → 请求体格式是否被代理改动。多数情况是路径没透传对。5.3 运行阶段的典型问题会话跑着跑着没反应了先别急着杀进程。用tmux attach进去看看可能是工具在等输入也可能是网络请求卡住了。如果是网络问题检查端点连通性。如果是工具本身卡死再考虑重启会话。还有一个常见现象AI 输出的内容太长终端滚动缓冲区不够用前面的内容看不到了。这时候 tmux 的复制模式就派上用场了开启鼠标模式后直接滚轮翻或者进复制模式搜索。报错/现象可能原因排查动作版本不存在版本号错误或源未同步改用 LTS 版本配置项被忽略拼写错误或版本不匹配对照文档核对键名代理转发失败路径或请求体未透传绕过代理逐层验证会话无响应等待输入或网络卡住attach 进去看状态输出看不到滚动缓冲区不足开启 tmux 鼠标模式5.4 我踩过的几个坑第一个坑是在 Windows 上直接用 CMD 跑 tmux。tmux 原生是 Unix 工具Windows 上要么用 WSL要么用兼容层。我一开始没注意折腾了半天发现根本跑不起来。后来统一在 WSL 里操作世界清净了。第二个坑是配置目录权限。在 Linux 上如果配置目录属主不对工具可能读不到配置却只给一个模糊的报错。养成习惯配置目录用当前用户创建权限别开得太随意。第三个坑是同时启动多个会话时资源抢占。如果你本地跑模型又同时开好几个 AI 会话内存和显存可能不够。我的做法是本地模型会话单独跑需要的时候再拉起不用的时候停掉别让它常驻占资源。6. 关于这套工作台后续可以怎么扩展搭好基础之后这套东西还有不少可以打磨的地方。比如给拉起脚本加上参数支持一键切换不同的模型端点比如把日志目录接一个简单的轮转避免日志无限增长再比如给 tmux 会话加上状态栏显示当前用的是哪个模型、哪个端点一眼就能看清。我个人的体会是openrig 这类方案的价值不在于它多复杂而在于它把“装工具”和“用工具”之间的那段混乱给理顺了。你不需要一次搭得很完美先把 Node.js、tmux、两个 CLI 工具跑通能稳定拉起会话就已经解决了八成的问题。剩下的边用边补遇到一个坑填一个坑慢慢就顺手了。真正让我省心的是那套“配置目录隔离 tmux 会话命名”的约定它让每次排查都有迹可循而不是对着一堆窗口猜哪个是哪个。