1. 从 openrig 这个名字说起它到底想解决什么问题第一次看到openrig这个词我脑子里蹦出来的不是某个具体工具而是一类需求。rig 在英文里有“装配、搭台子、把一堆零件组合成一套能干活的东西”的意思摄影里有 camera rig矿机圈有 mining rig到了 AI 编程工具这块rig 指的就是把模型、命令行、终端会话、编辑器插件这一整套东西拼成一个顺手的开发环境。前面加个 open基本可以判断这是一个开源取向的、帮你把环境搭起来的项目。那它为什么会在 Claude Code、Codex、Node.js、tmux 这几个词一起出现的时候被提到因为现在用 AI 辅助写代码的人普遍卡在同一个地方工具本身能装但装完之后怎么让它们协同工作怎么在一个终端里同时跑好几个会话怎么让 Claude Code 和 Codex 共用一套配置怎么在本地模型和云端模型之间切换这些“装配”层面的活儿没人系统讲。openrig 要处理的大概率就是这层装配问题。我先把话说在前面openrig目前公开信息很少项目正文和关键词都是空的所以下面所有关于它具体实现的描述都是基于“一个合格的 AI 开发环境装配工具应该长什么样”来做的合理推演结合 Claude Code、Codex、Node.js、tmux 这几个热词背后的真实痛点来展开。你把它当成一份“这类工具该怎么用、该怎么配”的实战参考而不是某个特定仓库的官方文档。适合读这篇的人有三类。第一类是刚接触 Claude Code 或 Codex装完发现命令行报一堆错、不知道从哪下手的新手。第二类是已经在用但每次开新项目都要重新配一遍、想把这套流程固化下来的中级用户。第三类是想把本地模型、云端模型、多个终端会话统一管理起来的老手。这三类人的需求层层递进我会按这个顺序把坑一个个填上。2. Node.js 环境所有麻烦的起点也是最多人栽跟头的地方2.1 为什么 Claude Code 和 Codex 都绕不开 Node.jsClaude Code 和 Codex 的 CLI 版本本质上都是 Node.js 写的命令行程序。你npm install -g装的那个包跑起来就是一个 Node 进程。这意味着 Node.js 的版本、npm 的全局路径、系统的 PATH 配置任何一环出问题你看到的报错都不是“Claude Code 坏了”而是“node 找不到”“npm 权限不足”“command not found”这类看起来跟 AI 毫无关系的错误。我见过太多人在这第一步就卡住然后去搜“claude code 安装失败”搜出来的答案五花八门其实根因就是 Node 环境没弄干净。所以 openrig 这类工具如果要做装配第一件事必然是检测和规范 Node 环境。2.2 版本选择LTS 不是随便说说的热词里有一条特别典型error installing 24.21.0: node.js v24.21.0 is not yet released or is not available。这个报错的意思是你想装的这个版本号根本不存在或者还没正式发布。很多人看到教程里写了个版本号就照着敲结果版本号是错的或者已经过时。正确的做法是永远优先选LTS长期支持版。LTS 版本经过充分测试生态兼容性最好Claude Code 和 Codex 这类工具官方测试的也是 LTS。当前 Node.js 的 LTS 主线是 20.x 和 22.x 系列具体小版本号会随时间更新所以不要死记某个数字而是去 Node.js 官网看当前标着 LTS 的那个。安装方式我强烈建议分平台处理Windows直接去 Node.js 官网下载 LTS 的.msi安装包双击一路下一步。安装时注意勾选“Add to PATH”这一步漏了后面全是坑。装完打开新的 PowerShell 或 CMD敲node -v和npm -v验证。macOS如果只是偶尔用官网.pkg安装包够了。但如果你要长期折腾多个版本用nvmNode Version Manager更省心可以随时nvm install 20切换。Ubuntu / Linux不要用apt install nodejs系统源里的版本往往很旧。用 NodeSource 的源或者同样上nvm。用 nvm 的话curl装完脚本后nvm install --lts一句搞定。提示装完 Node 之后务必关掉当前终端窗口重新开一个。PATH 环境变量的更新只在新的 shell 会话里生效很多人装完立刻在原窗口敲命令报 command not found然后以为装失败了其实只是没重开终端。2.3 npm 全局安装的权限坑Node 装好了接下来npm install -g anthropic-ai/claude-code或者对应的 Codex 包。在 macOS 和 Linux 上如果你没配好大概率会遇到EACCES permission denied。这是因为 npm 默认想把全局包装到系统目录而普通用户没权限。有两种解法。第一种是改 npm 的全局目录到用户目录下mkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后把~/.npm-global/bin加到 PATH 里在~/.bashrc或~/.zshrc里加一行export PATH~/.npm-global/bin:$PATHsource一下生效。第二种是用 nvmnvm 管理的 Node 天然把全局包放在用户目录不会有权限问题。我个人推荐第二种省事。Windows 上一般不会有权限问题因为默认装在用户目录下。但如果你用管理员权限装过一次后面用普通权限装就可能出现路径混乱这时候把 Node 彻底卸载重装是最干净的。2.4 验证环境是否真的干净装完之后别急着装 Claude Code先做一轮体检node -v # 应输出 v20.x 或 v22.x npm -v # 应输出对应版本 which node # 确认指向你刚装的那个不是系统自带的旧版 npm config get prefix # 确认全局路径如果which node指向/usr/bin/node而你明明用 nvm 装的说明 PATH 顺序有问题nvm 的初始化脚本没在 shell 配置里生效。这个细节决定了后面所有工具能不能正常跑值得多花五分钟确认。3. Claude Code 与 Codex 的安装、登录与那些绕不开的报错3.1 两个工具的定位差异决定了你怎么配Claude Code 和 Codex 虽然都是 AI 编程 CLI但使用逻辑不太一样。Claude Code 更偏向“在终端里跟模型对话让它直接读写你的项目文件、执行命令”它的强项是 agent 式的连续操作。Codex 的 CLI 更偏向“给它一个任务它生成代码或补丁”交互模式相对轻。这个差异直接影响你的配置策略Claude Code 需要更宽松的文件和命令权限Codex 则更关注模型端点和配置项的准确性。热词里codex is ignoring 1 unrecognized configuration setting. check for typos or d...这个报错就是典型的配置项写错。Codex 的配置文件对字段名很敏感多一个字母、少一个下划线都会触发这个警告。它不会直接崩但会忽略你那条配置导致你以为配了其实没生效。3.2 安装命令与常见失败Claude Code 的安装官方推荐用 npm 全局装。装完之后第一次运行会引导你登录。这里有个高频报错your organization has disabled claude subscription access for claude code。这个不是安装问题是账号权限问题——你所在的组织管理员关闭了 Claude Code 的访问权限。遇到这个只能找管理员开或者换个人账号。另一个高频词是note: claude code might not be available in your country。这是地区可用性提示属于服务端的限制不是本地环境能解决的。遇到这类提示先确认自己的账号和网络环境是否符合服务条款不要在这上面浪费时间折腾本地配置。Codex 的安装类似npm install -g对应的包之后codex命令启动。热词里codex无法加载组织设置和codex登录是绑在一起的通常是登录态失效或者组织配置拉取失败。处理顺序是先codex logout清掉旧凭证再重新codex login走一遍完整的授权流程。如果还不行检查是不是有代理或防火墙拦截了配置接口。3.3 登录态与凭证存放位置这两个工具登录后都会在用户目录下存凭证。Claude Code 一般在~/.claude或类似目录Codex 在~/.codex。这些目录里除了凭证还有配置和会话历史。当你遇到莫名其妙的登录问题时把这几个目录备份后清掉重新登录往往比逐条排查快得多。注意清凭证目录之前先确认里面没有你需要的会话记录或自定义配置。养成习惯把重要的配置项单独记一份别全指望工具自己存。3.4 在 VS Code 里用起来热词里vscode配置claude code、claude code for vs code、vscode接入claude code出现频率很高。说明很多人不满足于纯终端想在编辑器里直接用。思路是这样的Claude Code 本身是 CLIVS Code 里通过集成终端调用它或者装对应的扩展。扩展的作用通常是把 CLI 的输出渲染到编辑器面板里让你不用切窗口。配置的关键点在于VS Code 的集成终端要能读到和你外部终端一样的环境变量。如果你在.zshrc里配了 PATH但 VS Code 启动时没加载这个文件集成终端里就会找不到claude命令。解决办法是在 VS Code 设置里把默认终端 shell 指定对或者用terminal.integrated.env.*显式注入环境变量。Ubuntu 上配置 Claude Code 的坑主要在权限和路径。如果你用 snap 装的 VS Code它的沙箱机制可能导致集成终端读不到用户目录下的某些路径这时候换成官方.deb包安装会顺很多。4. tmux让多个 AI 会话并行工作的关键拼图4.1 为什么 AI 编程场景特别需要 tmuxtmux 是一个终端复用器直白说就是让你在一个终端窗口里开很多个“窗格”和“窗口”每个里面跑独立的会话而且这些会话在你断开连接后还能继续活着。为什么它跟 Claude Code、Codex 绑在一起被搜因为用 AI 写代码的典型工作流是这样的一个会话让 Claude Code 改前端一个会话让 Codex 写后端接口一个会话跑测试一个会话看日志。如果你只有一个终端就得不停切换而且一旦关掉窗口正在跑的任务就断了。tmux 解决的就是这个。你可以开一个 session里面分四个 pane每个 pane 跑一个 AI 工具或者一个服务然后 detach 掉去干别的回来 attach 继续看。对于需要长时间跑的任务比如让 AI 重构一个大文件tmux 几乎是刚需。4.2 最小可用配置tmux 装起来简单Ubuntu 上sudo apt install tmuxmacOS 上brew install tmux。但默认配置不好用前缀键是Ctrlb跟很多快捷键冲突。我建议改一下~/.tmux.conf# 把前缀键改成 Ctrla set -g prefix C-a unbind C-b bind C-a send-prefix # 开启鼠标支持方便点选窗格 set -g mouse on # 窗格从 1 开始编号 set -g base-index 1 setw -g pane-base-index 1改完tmux source-file ~/.tmux.conf生效。鼠标支持这一条特别重要开了之后你可以直接用鼠标点选窗格、拖动边框调整大小对不熟悉纯键盘操作的人友好太多。4.3 配合 AI 工具的实战用法我的习惯是给每个项目开一个 tmux session命名成项目名tmux new -s myproject进去之后Ctrla然后%左右分屏上下分屏。一个 pane 跑claude一个跑codex一个留给npm run dev或者测试命令。这样所有跟这个项目相关的东西都在一个 session 里Ctrla ddetach 之后哪怕关掉终端下次tmux attach -t myproject回来一切照旧。有个细节要注意Claude Code 这类工具在 tmux 里跑的时候如果窗格太小输出会换行错乱。所以分屏别分太碎每个 pane 至少保证 80 列宽。另外 tmux 里的滚动要用Ctrla [进入 copy mode或者开了鼠标支持直接滚轮。提示如果你在 tmux 里跑 Claude Code 发现颜色显示不对在.tmux.conf里加set -g default-terminal screen-256color然后重开 session。终端类型不对会导致很多 CLI 工具的彩色输出变成乱码。5. 本地模型接入Claude Code 调用 LM Studio 的完整链路5.1 为什么要接本地模型热词里claude code 调用lmstudio的本地模型和codex接入deepseek说明很多人不想只用官方云端模型。原因无非几个成本、隐私、离线可用、或者想用特定模型。LM Studio 是一个可以在本地跑开源模型的桌面工具它启动后会暴露一个兼容 OpenAI 接口的本地服务默认在http://localhost:1234。Claude Code 和 Codex 能不能接本地模型取决于它们是否支持自定义 API 端点。支持的话思路就是把请求指向 LM Studio 的地址把模型名换成你在 LM Studio 里加载的那个。5.2 配置的关键字段以兼容 OpenAI 接口的工具为例通常需要配这几个东西配置项值说明base_url / endpointhttp://localhost:1234/v1LM Studio 默认地址注意/v1api_key任意非空字符串本地服务不校验但不能留空modelLM Studio 里加载的模型标识在 LM Studio 界面能看到max_tokens根据模型上下文设置别超过模型上限配置写错最典型的表现就是连接被拒或者 404。先确认 LM Studio 的服务确实在跑浏览器访问http://localhost:1234/v1/models能看到模型列表再去配工具。这一步能排除掉一半的问题。5.3 本地模型的现实预期我得泼盆冷水。本地开源模型在代码任务上的表现跟云端大模型差距还是明显的尤其是复杂重构、多文件理解这类任务。本地模型适合的是简单的代码补全、格式转换、写点脚本、离线环境下的基础问答。你要是拿它跑 Claude Code 那种 agent 式的连续操作大概率会失望因为它可能连工具调用的格式都遵循不好。所以我的建议是本地模型当补充别当主力。日常用云端涉及敏感代码或者断网时切本地。切换这件事本身就是 openrig 这类工具想帮你自动化的——一键在云端和本地之间切不用手动改配置文件。6. 多模型切换与代理配置cc switch 这类工具的价值6.1 手动切换配置有多烦如果你同时用 Claude、DeepSeek、Qwen、GLM 这几个模型每个的 API 地址、密钥、模型名都不一样。手动改配置文件改完还得重启工具切来切去很容易把配置搞乱。热词里使用cc switch 接入 deepseek v4, qwen, glm等模型说的就是这类切换工具。cc switch 这类工具的核心功能是把多套配置存起来用一个命令切换当前生效的那套。它本质上是个配置管理器帮你改环境变量或者配置文件然后让 Claude Code / Codex 读到新的配置。6.2 切换失败的典型报错热词里有个很长的报错cc switch local proxy failed while handling codex endpoint /responses. provi...。这个信息量很大。它说明 cc switch 在中间起了一个本地代理把 Codex 的请求转发到目标模型。/responses是 Codex 用的端点路径代理在处理这个路径时失败了。可能的原因有几个目标模型的接口不兼容/responses这个路径很多第三方模型只兼容/chat/completions代理进程没起来或者端口被占配置里的 endpoint 拼写错误。排查顺序是先看代理进程在不在再看目标模型支持哪些路径最后核对配置。这类代理方案的本质是协议转换。Codex 说 OpenAI 的方言第三方模型说另一套方言代理在中间翻译。翻译规则没覆盖到的字段或者路径就会报错。所以用这类工具时选那些明确声明兼容 OpenAI 接口的模型成功率最高。6.3 第三方 API 使用的注意事项用第三方 API 有几个坑要提前知道。第一是速率限制第三方往往比官方严跑大批量任务容易被限流。第二是模型名第三方经常用自己的一套命名跟官方不一样配错了就连不上。第三是上下文长度第三方可能偷偷缩水你以为有 128k实际只有 32k长文件处理到一半就断了。我的做法是每接一个新模型先用一个最小请求测通确认返回正常再放到正式工作流里。别一上来就让它处理大项目出了问题都不知道是哪一环。7. 把整套环境固化下来openrig 思路的落地7.1 手工装配的问题在哪上面这些步骤——装 Node、装 Claude Code、装 Codex、配 tmux、接本地模型、配切换工具——每一步单独看都不难但合在一起就是几十个决策点。换台机器、重装系统、带新人都得重来一遍。而且很多配置是隐性的比如 PATH 的顺序、shell 配置文件的加载顺序、tmux 的终端类型这些不写下来根本记不住。openrig 这类工具如果存在价值就在于把这些决策固化成一个可复现的脚本或配置集。你 clone 下来跑一个命令环境就搭好了。7.2 一个可复现的装配清单就算没有现成工具你也可以自己维护一份。我把自己用的清单整理成下面这样按顺序执行装 nvm用 nvm 装 LTS Node避免权限和版本混乱。配 npm 全局路径如果用 nvm 可跳过确认 PATH。装 tmux应用.tmux.conf改前缀键、开鼠标。装 Claude Code 和 Codex各自登录验证基本命令能跑。配本地模型端点可选用 LM Studio 或类似工具测通/v1/models。配切换工具把常用模型的配置存好测通切换。写一个启动脚本一键开 tmux session 并分好窗格。这个清单的关键是顺序。Node 必须在最前面因为后面所有 npm 装的工具都依赖它。tmux 可以并行装但配置要在跑 AI 工具之前弄好否则终端显示问题会干扰你判断其他错误。7.3 启动脚本示例最后给一个我常用的 tmux 启动脚本放在项目根目录命名dev.sh#!/bin/bash SESSION$1 if [ -z $SESSION ]; then SESSIONdev fi tmux new-session -d -s $SESSION -n main tmux send-keys -t $SESSION:main claude C-m tmux split-window -h -t $SESSION:main tmux send-keys -t $SESSION:main codex C-m tmux split-window -v -t $SESSION:main tmux send-keys -t $SESSION:main npm run dev C-m tmux select-pane -t $SESSION:main.0 tmux attach -t $SESSION跑bash dev.sh myproject它会开一个 session左边跑 Claude Code右上跑 Codex右下跑开发服务器光标停在 Claude Code 那个窗格。这套流程我用了大半年换项目只改 session 名其他不用动。注意脚本里的命令名要跟你实际装的对上。如果你用的是别的包名或者别名改send-keys那几行。另外npm run dev换成你项目实际的启动命令。8. 几个我踩过、你大概率也会踩的坑第一个坑是PATH 顺序。系统自带的 Node 和你自己装的 Node 打架which node指向旧版导致 npm 装的全局包找不到。解决办法是确保自己装的 Node 路径在 PATH 里排在系统路径前面或者干脆把系统自带的卸了。第二个坑是shell 配置文件不生效。你在.zshrc里配了环境变量但 VS Code 的集成终端用的是.bash_profile两边不一致。统一用一个 shell或者把配置抽到一个公共文件里两边都 source。第三个坑是tmux 里的终端类型。不设default-terminal的话很多 CLI 工具的颜色和光标控制会出问题表现为输出乱码或者界面错位。这个坑很隐蔽因为工具本身没报错你只会觉得“怎么显示怪怪的”。第四个坑是配置文件的字段名。Codex 那个unrecognized configuration setting警告就是典型。第三方工具和官方文档的字段名经常对不上抄配置的时候逐字核对别凭印象写。第五个坑是本地模型的上下文长度。你以为加载的是 128k 上下文的模型实际 LM Studio 默认可能只给 4k长对话到一半就截断了。在 LM Studio 的加载设置里把 context length 调到你需要的值同时注意显存够不够。这些坑的共同点是报错信息都不直接指向根因。你得理解整个链路的依赖关系才能从表象反推到真正的问题所在。这也是为什么我建议先把环境体检做扎实再往上叠工具——地基不稳上面盖什么都会歪。