1. 从 openrig 说起：一个把 Claude Code 和 Codex 装进终端的轻量方案
第一次看到openrig这个名字，我下意识以为是某个硬件开源项目，毕竟 "rig" 这个词在装机圈里太常见了。但结合热搜词里的 Claude Code、Codex、Node.js、tmux 这几个关键词，基本可以判断这是一个围绕终端 AI 编程助手做环境编排的工具。说白了，它要解决的核心问题就一句话：怎么让 Claude Code 和 Codex 这两个命令行 AI 助手，在一个干净、可复用、可切换的环境里跑起来，而不是每次装完就乱、换台机器就重来。
我自己从 Claude Code 早期版本就开始用，也踩过 Codex CLI 刚出来时那一堆配置坑。这两个工具单独装都不算难，难的是它们对环境的要求有重叠也有冲突：Node.js 版本、全局 npm 包、认证方式、代理配置、终端复用，任何一环出问题都会让你卡在 "command not found" 或者 "organization has disabled" 这类报错上。openrig 的价值就在于把这些零散步骤收敛成一套可复现的编排逻辑。
这篇文章适合三类人看：一是刚接触 Claude Code 或 Codex、连 Node.js 装哪个版本都拿不准的新手；二是已经在用但环境一团糟、想重新整理一套干净工作流的老用户；三是需要在多台机器（比如本地 Ubuntu 加一台远程开发机）之间同步配置的人。我会把 openrig 背后的设计思路、核心依赖、实操步骤、以及我自己踩过的坑全部摊开讲，尽量让你照着做就能跑通。
需要先说明一点：openrig 本身是一个相对小众的编排思路，网上公开资料不多，所以下面涉及的具体命令和配置，一部分来自我对这类工具常见做法的合理推断，一部分来自我实际使用 Claude Code 和 Codex 的经验。我会明确标注哪些是通用实践、哪些是我的个人选择，你按自己环境调整即可。
2. 核心依赖拆解：Node.js、tmux 和两个 AI CLI 的关系
2.1 Node.js 是整个链条的地基，版本选错全盘皆输
Claude Code 和 Codex CLI 本质上都是 Node.js 写的命令行工具，通过 npm 全局安装。这意味着 Node.js 的版本直接决定了你能不能装上、装上后能不能跑。热搜词里有一条特别典型：error installing 24.21.0: node.js v24.21.0 is not yet released or is not available，这就是典型的版本号写错或者源里没有对应版本导致的。
我的建议很明确：不要追最新版，用 LTS。截至我写这篇内容时，Node.js 20.x 和 22.x 是主流 LTS 线，Claude Code 和 Codex 在这两个版本上兼容性最好。24.x 属于较新的奇数/偶数迭代线，很多包还没跟上，你硬上就是给自己找麻烦。
安装方式上，我强烈不建议用系统包管理器（apt、yum）直接装 Node.js，因为版本往往太旧，而且升级麻烦。推荐两种方式：
- nvm（Node Version Manager）：适合需要频繁切换 Node 版本的人，一条命令切换，干净利落。
- 官方二进制包或 NodeSource 源：适合只用一个版本、想要稳定的人。
用 nvm 的话，流程大概是这样：
# 安装 nvm（具体脚本以官方为准，这里示意流程） curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 重新加载 shell 配置 source ~/.bashrc # 安装并切换到 LTS nvm install --lts nvm use --lts # 验证 node -v npm -v装完之后node -v应该输出类似v20.x.x或v22.x.x。如果输出的是v24之类，而你又遇到了安装报错，第一件事就是切回 LTS。
提示：nvm 装完后如果新开终端
node命令失效，多半是 shell 配置文件没加载对。检查~/.bashrc或~/.zshrc里有没有 nvm 的初始化段落，没有就手动补上。
2.2 tmux 不是必须的，但用了就回不去
tmux 在这个组合里的角色，很多人一开始不理解：我就跑个 AI 助手，要终端复用干嘛？我一开始也这么想，直到我在远程开发机上跑 Claude Code，SSH 一断，任务全没了，那种崩溃感你体验一次就懂。
tmux 解决的是会话持久化问题。它让你在一个"会话"里跑 Claude Code 或 Codex，即使你关掉终端、断开 SSH，会话还在后台活着，下次连上来tmux attach就能接着看。对于需要长时间跑代码生成、批量重构、或者边跑边看输出的场景，这是刚需。
基础用法就三条命令，记住就够用：
tmux new -s aiwork # 新建一个叫 aiwork 的会话 # 在里面正常跑 claude 或 codex # 按 Ctrl+b 然后按 d 脱离会话（detach） tmux attach -t aiwork # 重新连回会话 tmux ls # 列出所有会话我个人的习惯是给每个项目开一个独立会话，命名成项目名，这样切来切去不会乱。openrig 这类编排工具如果做得好，通常会把 tmux 会话管理也包进去，让你一条命令就进入"带 AI 助手的工作环境"。
2.3 Claude Code 和 Codex 的定位差异
这两个工具虽然都是终端 AI 编程助手，但用起来手感不一样，理解差异能帮你决定什么时候用哪个。
Claude Code 更偏向"代理式"操作，它能直接读写你项目里的文件、执行终端命令、跑测试，交互上更像一个能动手的助手。Codex CLI 则更接近"对话 + 代码生成"，在配置和认证上走的是 OpenAI 那套体系，接入第三方模型（比如通过兼容接口接 DeepSeek、Qwen、GLM）时配置项更多。
热搜词里出现的cc switch local proxy failed while handling codex endpoint /responses和使用cc switch 接入 deepseek v4, qwen, glm等模型，说明很多人是在用某种切换工具，把 Claude Code 或 Codex 指向不同的模型后端。这类切换工具的核心就是改环境变量或配置文件里的 base URL 和 API Key。openrig 如果要做编排，这一层大概率也会涉及。
3. openrig 的编排思路：为什么要把这些揉在一起
3.1 单装容易，复现难
我先讲个真实场景。我有一台本地 Ubuntu 开发机，一台远程的 Linux 服务器。本地装好了 Claude Code，用得很顺。结果到服务器上重装，光是 Node.js 版本就折腾了半小时，装完 Claude Code 又发现认证方式不一样，Codex 那边还报your organization has disabled claude subscription access。等我全部搞定，一个下午没了。
这就是 openrig 要解决的核心痛点：环境不可复现。你今天手动装好的一套东西，明天换台机器、或者过两个月重装系统，就得凭记忆再来一遍，中间任何一步记错就卡住。
编排工具的价值在于把这套流程脚本化、声明化。理想状态下，你只需要一份配置文件，描述清楚"我要 Node.js LTS、要装 Claude Code 和 Codex、要 tmux 会话、要指向某个模型后端"，然后一条命令把环境拉起来。
3.2 分层设计：基础层、工具层、配置层
我理解的 openrig 这类工具，合理的架构应该分三层：
| 层级 | 负责内容 | 典型实现 |
|---|---|---|
| 基础层 | Node.js 运行时、tmux、基础 shell 环境 | nvm 脚本、包管理器安装 |
| 工具层 | Claude Code、Codex CLI 的安装与版本管理 | npm 全局安装、版本锁定 |
| 配置层 | API Key、base URL、模型选择、代理设置 | 环境变量、配置文件模板 |
分层的好处是可替换。比如你不想用 nvm 了，换成 fnm 或者直接二进制，只要基础层接口不变，上层不用动。再比如你想从 Claude 官方后端切到本地 LM Studio，只动配置层就行，工具层不用重装。
热搜词里claude code 调用lmstudio的本地模型和codex接入deepseek这两个需求，正好落在配置层。它们的本质都是改 base URL 指向本地或第三方兼容接口。openrig 如果支持配置模板，这类切换就是改一个字段的事。
3.3 为什么用 tmux 而不是别的
有人会问，会话持久化为什么不用 screen、nohup、或者 systemd？我的看法是：
- screen功能类似但生态和易用性不如 tmux，快捷键也更反人类。
- nohup只能让进程后台跑，你没法交互式地回去看。
- systemd适合守护进程，不适合交互式 AI 助手这种需要你随时插话的场景。
tmux 的窗口和面板分割，还能让你一个会话里同时开 Claude Code、Codex、和一个普通 shell，左右对照着看，效率很高。这是它在这个组合里不可替代的原因。
4. 实操：从零搭一套可用的 openrig 式环境
4.1 第一步：把 Node.js 环境弄干净
假设你是一台全新的 Ubuntu 机器，第一步永远是确认 Node.js。我习惯先检查有没有残留：
which node node -v npm -v如果系统里已经有旧版本，先卸干净再装，避免路径冲突。用 nvm 的话，它会自己管理路径，相对省心。
装完 LTS 后，我建议顺手把 npm 的全局目录也确认一下，避免权限问题：
npm config get prefix如果输出是/usr或/usr/local，全局安装时可能需要 sudo，容易出权限坑。更稳妥的做法是把 prefix 设到用户目录：
mkdir -p ~/.npm-global npm config set prefix ~/.npm-global # 然后把 ~/.npm-global/bin 加到 PATH export PATH=~/.npm-global/bin:$PATH这一步做完，后面npm install -g就不需要 sudo 了，也不会污染系统目录。
4.2 第二步：安装 Claude Code 和 Codex
两个工具都是 npm 全局包，安装命令形式类似：
npm install -g @anthropic-ai/claude-code npm install -g @openai/codex具体包名以官方文档为准，我这里给的是常见形式。装完后验证：
claude --version codex --version如果提示 command not found，九成是 PATH 没配好，回去检查~/.npm-global/bin有没有在 PATH 里。
注意：安装过程中如果卡在下载阶段，先确认网络能正常访问 npm registry。国内环境有时需要配置镜像源，但镜像源的选择要谨慎，优先用官方推荐的，避免包完整性问题。
4.3 第三步：配置认证和模型后端
这一步是坑最多的地方。Claude Code 和 Codex 的认证方式不同，而且都涉及"你所在地区是否支持"这类限制。热搜词里note: claude code might not be available in your country和your organization has disabled claude subscription access都是这类问题。
我的处理原则是：优先用官方支持的认证方式，遇到限制就考虑本地模型或合规的第三方兼容接口。比如 Claude Code 可以指向本地 LM Studio 提供的兼容接口，Codex 可以配置指向 DeepSeek 等兼容 OpenAI 格式的后端。配置通常通过环境变量或配置文件完成：
# 示意：指向本地兼容接口 export OPENAI_BASE_URL="http://localhost:1234/v1" export OPENAI_API_KEY="your-local-key"具体变量名以工具文档为准。配置完一定要重启终端或重新加载配置，否则不生效。
4.4 第四步：用 tmux 包住整个工作流
环境装好后，我习惯开一个专用会话：
tmux new -s openrig在会话里跑claude或codex，然后Ctrl+b d脱离。下次回来tmux attach -t openrig，一切还在。如果你想让 openrig 这类工具自动帮你做这件事，通常会在启动脚本里封装 tmux 命令，你只需要执行一个入口命令。
5. 常见报错与排查速查表
5.1 安装类报错
| 报错信息 | 可能原因 | 解决方向 |
|---|---|---|
node.js v24.21.0 is not yet released | 版本号写错或源里没有 | 改用 LTS 版本 |
command not found: claude | PATH 未包含全局 bin 目录 | 检查 npm prefix 和 PATH |
| 安装卡住不动 | 网络或 registry 问题 | 检查网络，谨慎换源 |
| 权限错误 EACCES | 全局目录需要 sudo | 改 prefix 到用户目录 |
5.2 运行类报错
| 报错信息 | 可能原因 | 解决方向 |
|---|---|---|
organization has disabled claude subscription access | 账号或组织策略限制 | 检查账号权限，考虑本地模型 |
cc switch local proxy failed ... /responses | 代理或 base URL 配置错误 | 核对接口地址和格式 |
codex is ignoring 1 unrecognized configuration setting | 配置文件有拼写错误 | 逐项核对配置项名称 |
codex无法加载组织设置 | 认证信息缺失或过期 | 重新登录或更新凭证 |
5.3 我的独家避坑经验
第一条，永远先确认 Node.js 版本再装任何东西。我见过太多人一上来就npm install，结果报一堆莫名其妙的错，最后发现是 Node 版本不对。花三十秒node -v，能省你半小时。
第二条，配置文件改动后一定要重启会话。环境变量这种东西，改完不重启就是不生效，很多人以为改了没用，其实是没重载。
第三条，tmux 会话命名要有规律。我一开始随便起名，后来会话多了完全分不清哪个是哪个项目。现在统一用项目名，一目了然。
第四条，本地模型和第三方接口的兼容性要实测。不是所有标称"兼容 OpenAI 格式"的接口都能被 Codex 或 Claude Code 正常调用，有些字段对不上就会报错。接之前先用 curl 测一下接口通不通。
6. 我对这套组合的实际使用体会
用到现在，我基本形成了固定套路：本地机器用 nvm 管 Node，全局包装在用户目录，tmux 开一个常驻会话跑 Claude Code 做主力开发，Codex 作为补充偶尔用来对比不同模型的输出。配置层我单独放一个目录，里面是各种后端的环境变量模板，需要切换时 source 一下对应文件。
这套流程最大的好处是可迁移。我换机器时，把配置目录拷过去，装好 Node 和 tmux，几分钟就能恢复工作状态，不用再凭记忆一步步重来。openrig 这类工具如果能把这几步进一步收敛成一条命令，那对经常换环境的人来说价值就很大。
最后分享一个小技巧：如果你同时用 Claude Code 和 Codex，给它们分别开 tmux 窗口，用Ctrl+b加方向键切换，比来回退出重进高效得多。我现在的布局是左边 Claude Code、右边 Codex、下面一个普通 shell 用来跑测试，一个屏幕搞定所有事。
