1. 从“openrig”说起：一个把 Claude Code 和 Codex 装进同一台机器的实战思路
第一次看到openrig这个词，我下意识把它拆成了 “open” 和 “rig” 两半。rig 在工程语境里指的是“把一堆零散部件组装成一套能跑起来的装置”，放到开发工具这个场景里，它其实就是在说一件事：把 Claude Code、Codex 这类命令行 AI 编程助手，连同 Node.js、tmux 这些底层依赖，搭成一套随时能开工的本地环境。这套东西不解决什么高深的算法问题，它解决的是更烦人的问题——你换了台机器、重装了系统、或者想同时用两个不同的 AI 编程助手，结果发现环境配置能把人折腾一下午。
我身边不少朋友最近都在折腾 Claude Code 和 Codex，热搜里那些词我扫了一眼，几乎全是安装、配置、登录、报错相关的：claude code安装、codex安装教程、node.js安装、codex登录、vscode配置claude code、ubuntu配置claude code。这说明什么？说明大家卡住的根本不是“AI 能不能写代码”，而是“我连装都装不明白”。openrig这个标题背后，我理解的核心诉求就是：用一套清晰、可复现的流程，把 Claude Code 和 Codex 这两个主流 CLI 工具，在 Node.js 和 tmux 的支撑下，稳稳当当地跑起来，并且能长期用下去。
这篇文章适合谁看？如果你是完全没碰过命令行 AI 助手的新手，我会从 Node.js 是干什么的讲起，把每一步都拆开；如果你已经装过但总在某个环节翻车，比如codex is ignoring 1 unrecognized configuration setting或者cc switch local proxy failed，那第三、四部分的排查思路应该能帮到你。我不打算写成官方文档的复读机，而是按一个真实搭过好几轮环境的人的视角，把踩过的坑、绕过的弯、以及那些文档里不会写的细节，一条条摊开讲。
2. 整体设计思路：为什么是 Node.js + tmux + 双 CLI 这套组合
2.1 先搞清楚每个部件到底在干什么
很多人一上来就照着教程敲命令，敲完报错也不知道错在哪，根本原因是没搞明白这套工具链里每个角色负责什么。我用一个生活化的类比来说明：把整套环境想象成一家小餐馆。
Node.js 是这家餐馆的“水电煤基础设施”。Claude Code 和 Codex 这两个 CLI 工具本质上都是用 JavaScript/TypeScript 生态构建的命令行程序，它们依赖 Node.js 运行时才能启动。热搜里有人问node.js是干什么的，答案很简单：它让 JavaScript 能脱离浏览器，直接在操作系统上跑。你装 Claude Code 时看到的npm install -g，那个 npm 就是 Node.js 自带的包管理器。所以 Node.js 装不对，后面全是空中楼阁。
tmux 是“后厨的分区操作台”。它的核心价值是会话保持。你在 SSH 连到远程服务器跑 Claude Code 时，如果网络抖一下、终端断开，没有 tmux 的话，正在跑的会话直接没了。tmux 让你把会话挂在后台，断开重连后tmux attach就能回到原来的界面。热搜里tmux能和claude code并列出现，说明已经有人意识到长任务场景下会话保持的重要性了。
Claude Code 和 Codex 是“两位不同菜系的主厨”。它们都是命令行 AI 编程助手，但背后的模型、交互风格、配置方式有差异。Claude Code 是 Anthropic 家的，Codex 是 OpenAI 家的 CLI 工具。同时装两个的好处是：不同任务用不同工具，比如一个擅长长上下文重构，一个在某些语言上响应更快，你可以按需切换。openrig的“rig”精神就体现在这里——不是二选一，而是让它们共存。
2.2 为什么强调“本地组装”而不是“云端开箱”
现在很多 AI 编程工具都提供网页版或者云端 IDE 集成，为什么还要费劲在本地搭 CLI？我总结下来有三个理由，这也是openrig这套思路的立足点。
第一是数据可控。CLI 工具在你的机器上运行，代码文件、上下文、会话记录都在本地，你可以自己决定哪些目录让它访问。对于公司内部项目，这一点比什么都重要。
第二是可组合性。CLI 工具能和你现有的工具链无缝拼接：git、make、docker、各种脚本，全都能串起来。网页版做不到这种深度集成。热搜里claude code如何直接执行终端命令这个问题，答案就是 CLI 天然具备这个能力，它本来就在终端里。
第三是成本与配额。热搜里出现了your organization has disabled claude subscription access for claude code和note: claude code might not be available in your country，说明订阅和可用性是有门槛的。本地 CLI 配合第三方 API 或者本地模型（热搜里claude code 调用lmstudio的本地模型、codex接入deepseek都是这个方向），能给你更多选择余地，不被单一渠道卡死。
2.3 方案选型的几个关键取舍
在动手之前，有几个决策点值得先想清楚，这决定了你后面少走多少弯路。
Node.js 版本怎么选。热搜里有个很典型的报错：error installing 24.21.0: node.js v24.21.0 is not yet released or is not available。这就是版本选错了。我的建议是永远优先选LTS（长期支持）版本，而不是追最新的 Current 版本。LTS 版本经过充分测试，生态兼容性最好。Claude Code 和 Codex 对 Node.js 版本都有最低要求，但通常不会要求你必须用最新版。装 LTS，稳。
包管理器用 npm 还是别的。新手直接用 npm 就行，它是 Node.js 自带的，零额外配置。等你熟悉了再考虑 pnpm 或 yarn。不要一上来就追求“高级”，工具是拿来用的，不是拿来炫的。
全局安装还是项目内安装。Claude Code 和 Codex 这类 CLI 工具，我建议全局安装（npm install -g），因为你要在任何目录下都能调用它们。项目内安装适合那种只在特定仓库里用的工具。
tmux 要不要一开始就上。如果你只在本机用，不涉及远程服务器，tmux 可以先不装。但只要你有一台远程开发机，或者任务可能跑很久，tmux 就是刚需。我个人的习惯是：只要开终端干活，第一件事就是tmux new -s work。
3. 核心细节解析：Node.js 与 tmux 的安装要点
3.1 Node.js 安装：别去官网随便下，先看版本
热搜里node.js官网下载、node.js lts下载、安装node.js、node.js下载反复出现，说明这是第一道坎。我见过太多人直接去官网首页点了那个最大的下载按钮，结果下到了 Current 版本，然后遇到各种兼容问题。
正确的做法是这样：打开 Node.js 官网，找到 LTS 那一栏，看清楚版本号。截至我写这篇内容时，LTS 主线在 20.x 和 22.x 之间，具体以官网为准。下载对应你操作系统的安装包。
Windows 用户直接下.msi安装包，双击一路下一步即可，安装程序会自动把node和npm加进 PATH。装完后打开新的 PowerShell 或 CMD，输入：
node -v npm -v两条命令都能输出版本号，才算装好。如果提示“不是内部或外部命令”，八成是 PATH 没生效，关掉终端重开一次，或者重启电脑。
macOS 用户我强烈建议用 Homebrew 装，比下 pkg 包省心：
brew install node@22Ubuntu 用户别用apt install nodejs，那个版本往往太老。用 NodeSource 的源：
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt-get install -y nodejs注意：热搜里那个
node.js v24.21.0 is not yet released的报错，本质是你指定的版本号根本不存在。装之前一定去官网确认当前真实存在的版本号，别凭记忆敲。
3.2 npm 全局目录的权限坑
这是新手最容易翻车的地方，尤其在 macOS 和 Linux 上。当你执行npm install -g时，如果提示EACCES权限错误，说明 npm 的全局目录归 root 所有，普通用户写不进去。
网上有些教程会让你sudo npm install -g，我不建议这么做。用 sudo 装全局包会带来两个后患：一是后续升级、卸载都可能需要 sudo，二是某些包在运行时以 root 身份执行脚本，有安全风险。
正确的做法是给当前用户配置一个专属的全局目录。先看看当前配置：
npm config get prefix如果输出是/usr/local或/usr，就改成用户目录下的路径：
mkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后把~/.npm-global/bin加进 PATH。在~/.bashrc或~/.zshrc里加一行：
export PATH=~/.npm-global/bin:$PATH重新加载配置后，再装全局包就不需要 sudo 了。这一步做完，后面装 Claude Code 和 Codex 会顺畅很多。
3.3 tmux 安装与最常用的几个操作
tmux 在 Ubuntu/Debian 上：
sudo apt install tmuxmacOS 上：
brew install tmux装完之后，你不需要背一大堆快捷键，先掌握这几个就够日常用了：
tmux new -s work：新建一个叫 work 的会话tmux ls：列出所有会话tmux attach -t work：重新连接到 work 会话tmux detach：在会话内按Ctrl+b然后按d，把会话挂到后台tmux kill-session -t work：彻底结束某个会话
我个人的工作流是这样的：SSH 登录远程机器后，第一件事tmux new -s dev，然后在里面启动 Claude Code 或 Codex。这样即使我本地网络断了、笔记本合盖了，远程的会话还在跑，重新连上tmux attach -t dev就回到原样。热搜里claude code如何直接执行终端命令配合 tmux 使用，体验会好很多，因为长命令执行不会因为断线而中断。
提示：tmux 默认的前缀键是
Ctrl+b。如果你觉得别扭，可以在~/.tmux.conf里改成Ctrl+a，加一行set -g prefix C-a即可。
4. Claude Code 与 Codex 的安装配置实操
4.1 Claude Code 安装：从零到能对话
Claude Code 的安装本身不复杂，复杂的是登录和权限。先装：
npm install -g @anthropic-ai/claude-code装完后在任意项目目录下输入claude，它会引导你完成登录。这里会遇到热搜里提到的几个典型问题。
问题一：your organization has disabled claude subscription access for claude code。这个报错的意思是，你当前登录的账号所属组织，管理员关闭了 Claude Code 的访问权限。如果你用的是公司统一分配的账号，需要找管理员开通；如果是个人账号，检查一下订阅类型是否支持 Claude Code。
问题二：note: claude code might not be available in your country。这是可用性提示，说明你所在区域不在官方支持列表内。遇到这个，通常的解决路径是使用第三方 API 接入方式，也就是热搜里使用cc switch 接入 deepseek v4, qwen, glm等模型提到的思路——通过配置把 Claude Code 的后端指向其他兼容的模型服务。
问题三：cc switch local proxy failed while handling codex endpoint /responses。这个报错信息里同时出现了 cc switch 和 codex endpoint，说明你在用某个切换工具同时管理 Claude Code 和 Codex 的后端，而代理在处理 Codex 的/responses端点时失败了。这类问题的排查思路我在第 5 部分详细讲。
Claude Code 装好后，建议在项目根目录放一个配置文件，明确它能访问哪些目录。默认情况下它会读取当前工作目录，你可以通过启动参数或配置文件限制范围，避免它误操作到不该碰的文件。
4.2 Codex 安装：注意配置项的拼写
Codex 的 CLI 安装同样走 npm：
npm install -g @openai/codex装完后输入codex启动。热搜里codex登录、codex配置、codex汉化、codex安装 windows桌面版都是高频问题。我挑几个重点说。
登录环节。Codex 需要你提供 API 凭证。第一次运行会提示你输入 API Key，或者引导你走浏览器授权流程。如果你在公司网络环境下，注意代理设置可能会影响授权回调。
配置项拼写。热搜里codex is ignoring 1 unrecognized configuration setting. check for typos or d这个警告非常常见。它的意思是：你的配置文件里有一个它不认识的配置项，可能是拼写错了，也可能是版本更新后这个配置项被废弃了。解决方法是打开配置文件（通常在~/.codex/config或项目内的.codex目录），逐项核对官方文档里的配置项名称。我踩过的坑是把model拼成了modle，找了半天才发现。
接入第三方模型。热搜里codex接入deepseek说明很多人想把 Codex 的后端换成 DeepSeek 等模型。这通常需要修改配置文件里的base_url和api_key，指向兼容 OpenAI 接口格式的服务。配置时注意两点：一是base_url要包含正确的路径前缀，二是模型名称要和对方服务商文档里的一致。
4.3 让两个工具和平共处
同时装 Claude Code 和 Codex，最容易冲突的地方是环境变量和配置文件。两者可能都读取OPENAI_API_KEY之类的通用变量，或者都往同一个目录写缓存。
我的做法是给它们各自独立的配置目录，通过启动时的环境变量区分。比如在 shell 里定义两个别名：
alias cc='ANTHROPIC_CONFIG_DIR=~/.config/claude-code claude' alias cx='OPENAI_CONFIG_DIR=~/.config/codex codex'这样两个工具的配置互不干扰，切换时也不会串味。热搜里cc switch这类工具本质上就是在帮你做这件事，但如果你只是偶尔切换，手动管理别名反而更透明、更好排查。
5. 常见问题与排查技巧实录
5.1 安装类问题速查表
| 报错信息关键词 | 可能原因 | 排查方向 |
|---|---|---|
node.js vXX is not yet released | 版本号不存在 | 去官网确认当前 LTS 版本号 |
EACCES权限错误 | npm 全局目录归 root | 配置用户级 prefix，别用 sudo |
command not found: claude | 全局 bin 目录不在 PATH | 检查npm config get prefix并加入 PATH |
unrecognized configuration setting | 配置项拼写错误或已废弃 | 对照官方文档逐项核对 |
local proxy failed ... /responses | 代理工具处理端点失败 | 检查代理配置和端点路径 |
organization has disabled ... access | 组织管理员关闭权限 | 联系管理员或换个人账号 |
5.2 代理与端点问题的排查思路
热搜里cc switch local proxy failed while handling codex endpoint /responses这个报错，信息量很大。我拆解一下排查步骤。
第一步，确认代理工具本身是否在运行。很多切换工具会在本地起一个 HTTP 服务，如果这个服务没起来，所有请求都会失败。检查方法通常是看它的日志输出，或者用curl直接访问它的本地端口。
第二步，确认端点路径。Codex 用的是/responses端点，而有些代理工具默认按/v1/chat/completions这种传统格式转发，路径对不上就会报错。你需要检查代理工具的配置，看它是否正确识别了 Codex 的请求格式。
第三步，确认上游服务的兼容性。如果你把 Codex 指向了一个只支持传统 chat 接口的服务，而 Codex 发的是 responses 格式的请求，那上游会直接拒绝。这时候要么换一个兼容的服务，要么在代理层做格式转换。
提示：遇到代理类问题，最有效的办法是打开详细日志。大多数工具都支持
--verbose或DEBUG=*环境变量，把请求和响应的原始内容打出来，问题往往一眼就能看到。
5.3 我踩过的几个真实坑
坑一：在错误的目录下启动。有一次我在 home 目录直接敲claude，结果它把整个 home 目录当成了工作区，扫描了一堆无关文件，响应特别慢。后来我养成了习惯：先cd到具体项目目录，再启动工具。
坑二：tmux 里环境变量丢失。在 tmux 会话里启动 Claude Code，发现它读不到我在.zshrc里配的 API Key。原因是 tmux 启动时的 shell 环境和你登录时的环境可能不一致。解决办法是在 tmux 配置里加上set-option -g update-environment "ANTHROPIC_API_KEY OPENAI_API_KEY"，或者干脆在会话内手动export一次。
坑三：Node.js 版本升级后全局包失效。用 nvm 管理 Node.js 版本的人要注意，切换版本后，之前装在旧版本下的全局包在新版本里是找不到的。需要在新版本下重新npm install -g。这也是我建议固定用一个 LTS 版本、别频繁切换的原因。
坑四：配置文件里的注释导致解析失败。有些工具的配置文件是严格的 JSON 格式，不支持注释。我习惯性加了//注释，结果工具直接报解析错误。后来改用 JSON5 或者干脆把说明写在外部文档里。
6. 把环境用顺手的几个进阶习惯
6.1 用 tmux 会话命名规范管理多任务
当你同时跑多个 AI 编程任务时，tmux 会话会越开越多。我的命名规范是项目名-用途，比如myapp-refactor、myapp-test、tools-debug。这样tmux ls一眼就能看清每个会话在干什么，不会误杀正在跑的任务。
配合 tmux 的窗口（window）和面板（pane）功能，你可以在一个会话里左边跑 Claude Code，右边跑 Codex，下面开一个 shell 看日志。这种布局一旦用顺了，效率提升非常明显。
6.2 给两个工具准备独立的项目配置
在项目根目录放工具专属的配置文件，能让协作更规范。比如 Claude Code 可以读CLAUDE.md来了解项目背景和约定，Codex 也有类似的机制。把项目的技术栈、代码规范、常用命令写进去，AI 助手的回答质量会明显提升。
我通常会在CLAUDE.md里写清楚：这个项目用什么语言、什么框架、测试怎么跑、提交信息格式是什么。这些信息不需要多详细，但能让 AI 少问很多废话。
6.3 定期清理和更新
CLI 工具更新很频繁，建议每隔一两周检查一次：
npm outdated -g npm update -g但别盲目追新。如果当前版本用得好好的，没有遇到 bug，可以缓一缓再升。升级前最好看一眼更新日志，确认没有破坏性变更。我就遇到过某次升级后配置文件格式变了，折腾了半天才恢复。
6.4 关于本地模型接入的补充
热搜里claude code 调用lmstudio的本地模型这个方向值得单独提一句。如果你对数据隐私要求高，或者想省 API 费用，可以把 Claude Code 或 Codex 的后端指向本地运行的模型服务。LM Studio 这类工具能在本地起一个兼容 OpenAI 接口的服务，你只需要把 CLI 工具的base_url指向http://localhost:端口，再填一个占位的 API Key 即可。
不过要提醒一句：本地模型的能力和云端大模型有差距，复杂任务上体验会打折扣。适合的场景是简单的代码补全、格式转换、文档生成，别指望它做大型重构。
这套openrig的思路，说到底就是把工具链的每一环都摸清楚，然后按自己的习惯组装起来。装的时候多花半小时搞明白原理，用的时候能省下几十个小时的排查时间。我现在换新机器，从零到两个 CLI 工具都能跑，基本控制在二十分钟以内，靠的就是这套流程和踩过的那些坑。
