1. 从“openrig”说起一个把 Claude Code 和 Codex 装进同一台机器的实战思路第一次看到 “openrig” 这个词我脑子里蹦出来的不是某个具体软件而是一类需求把散落在不同终端、不同模型、不同会话里的 AI 编码助手整合成一套自己能掌控的“工作台”。热词里反复出现 Claude Code、Codex、Node.js、tmux还有一堆安装报错和配置问题说明大家真正卡住的不是“要不要用”而是“怎么把它们装好、连上、跑顺、不打架”。我自己的场景很典型一台 Ubuntu 开发机偶尔切 Windows 桌面版主力用 Claude Code 做代码理解和重构用 Codex 做补全和批量改写本地还挂着 LM Studio 跑小模型做离线兜底。问题在于每个工具都有自己的安装方式、认证流程、配置目录和终端依赖装完一个另一个就报错tmux 会话一关上下文全丢。openrig 这个标题给我的启发是不要把它当成一个现成软件而是当成一套“开放工作台”的搭建方法论——用 Node.js 做运行时底座用 tmux 做会话保持用统一的配置管理把 Claude Code 和 Codex 的接入路径理清楚。这篇文章适合谁看如果你正在 Ubuntu 或 Windows 上折腾 Claude Code 安装、Codex 安装被 Node.js 版本、组织权限、代理端点、配置拼写这些事搞得头大或者想让本地模型和云端模型在同一个终端里切换那这篇就是写给你的。我会按“整体设计—核心细节—实操过程—问题排查”的顺序把每一步为什么这么做、参数怎么定、坑在哪里全部摊开讲。全文基于常见工程实践补全细节不涉及任何敏感工具只谈本地开发环境的组织方式。2. 整体设计与思路拆解为什么是 Node.js tmux 统一配置层2.1 为什么把 Node.js 当作底座而不是随便装一个版本Claude Code 和 Codex 的 CLI 形态本质上都是 Node.js 生态里的命令行工具。热词里出现 “node.js安装”“node.js官网下载”“node.js lts下载”“error installing 24.21.0: node.js v24.21.0 is not yet released” 这些说明很多人的第一道坎就是 Node.js 本身。我的建议很明确不要追最新版用 LTS。原因有三点。第一CLI 工具依赖的 npm 包在 LTS 上经过更充分的兼容性验证。Node.js 的奇数版本和刚发布的偶数版本经常出现原生模块编译失败尤其是涉及终端交互、文件监听、加密库的场景。第二LTS 的生命周期长你不需要每隔几周就重新处理一次运行时升级带来的连锁问题。第三很多安装脚本内部会检查 Node 版本范围非 LTS 版本可能直接触发 “not yet released or is not available” 这类拒绝逻辑。具体操作上我推荐用版本管理器而不是系统包管理器直接装。Ubuntu 上可以用 nvmWindows 上可以用 nvm-windows 或者直接装官方 LTS 安装包。用版本管理器的好处是当某个工具明确要求 Node 18 而另一个要求 Node 20 时你可以用nvm use快速切换而不是把系统环境搞乱。这一点在多工具共存的 openrig 场景里非常关键。提示安装完 Node.js 后先用node -v和npm -v确认版本再执行任何 CLI 安装命令。很多“安装失败”其实是 Node 根本没装好或者 PATH 没生效。2.2 tmux 在 openrig 里的角色不是可选是刚需热词里 “tmux” 和 “claude code如何直接执行终端命令” 同时出现这不是巧合。Claude Code 这类工具经常需要长时间运行、需要保持会话上下文、需要在执行终端命令时不中断。如果你直接在一个普通终端窗口里跑SSH 一断、窗口一关会话就没了。tmux 解决的就是这个问题它把终端会话和窗口解耦你可以随时断开再回来会话里的进程继续跑。在 openrig 的设计里tmux 承担三个职责。第一会话保持Claude Code 和 Codex 可以各自跑在独立的 tmux window 里互不干扰。第二日志留存tmux 的 scrollback buffer 可以保留大量输出方便回溯模型返回的内容。第三多任务并行一个 window 跑 Claude Code 做代码审查另一个 window 跑 Codex 做批量改写第三个 window 跑本地 LM Studio 的服务端切换只用快捷键。我通常这样组织tmux new -s openrig创建一个名为 openrig 的会话然后Ctrlb c创建多个 window分别命名为 claude、codex、local。这样即使我关掉终端去开会回来tmux attach -t openrig一切照旧。这个习惯一旦养成你会发现 AI 编码助手的使用体验提升一个档次因为上下文不再因为网络抖动而丢失。2.3 统一配置层的价值让 Claude Code 和 Codex 不打架Claude Code 和 Codex 各有自己的配置目录和认证方式。Claude Code 通常涉及订阅访问权限热词里 “your organization has disabled claude subscription access for claude code” 就是典型的权限问题。Codex 则涉及组织设置、配置项拼写、端点路径热词里 “codex is ignoring 1 unrecognized configuration setting. check for typos” 和 “cc switch local proxy failed while handling codex endpoint /responses” 都是配置层面的坑。openrig 的思路是不要试图让两个工具共享同一份配置而是建立清晰的隔离和切换机制。具体来说每个工具用独立的配置目录通过环境变量或启动参数指定模型接入点比如本地 LM Studio 的地址、第三方 API 的 base URL集中记录在一个文档或脚本里切换时只改一处。这样做的理由是两个工具的配置格式、字段名、认证 header 都不一样强行合并只会导致 “unrecognized configuration setting” 这类问题。我自己的做法是在 home 目录下建一个~/openrig/文件夹里面放claude.env、codex.env、models.md三个文件。claude.env和codex.env分别记录各自需要的环境变量models.md记录本地模型和第三方 API 的接入信息。启动时用source加载对应文件避免环境变量互相污染。这个方案看起来土但实测下来最稳排查问题也最快。3. 核心细节解析与实操要点安装、配置、接入的每一步3.1 Node.js 安装避开版本陷阱和 PATH 问题Ubuntu 上的推荐流程是这样。先更新包索引然后通过 nvm 安装 LTS。如果你直接用apt install nodejs很可能装到的是发行版仓库里的旧版本导致后续 CLI 工具要求的最低版本不满足。用 nvm 的命令大致是先下载安装脚本执行后 source 一下 shell 配置然后nvm install --lts再nvm alias default lts/*。这样新开的终端默认就用 LTS。Windows 上更简单去 Node.js 官网下载 LTS 的.msi安装包安装时勾选 “Add to PATH”。安装完成后打开新的 PowerShell 或 CMD执行node -v验证。如果你遇到 “error installing 24.21.0: node.js v24.21.0 is not yet released or is not available”说明你指定的版本号不存在或者还没正式发布换成--lts或者具体的 LTS 版本号即可。注意不要同时用系统包管理器和 nvm 管理 Node.js否则 PATH 里会出现多个 node 可执行文件导致版本混乱。装之前先which node看一眼如果指向/usr/bin/node考虑先清理或调整 PATH 优先级。3.2 Claude Code 安装与权限问题的处理逻辑Claude Code 的安装通常通过 npm 全局安装或者官方提供的安装脚本。安装完成后第一次运行会触发认证流程。热词里 “your organization has disabled claude subscription access for claude code” 和 “note: claude code might not be available in your country” 说明两个问题一是组织管理员可能关闭了订阅访问二是区域可用性限制。对于组织权限问题你能做的是确认自己使用的账号是否在允许列表里或者换用个人账号。对于区域提示这属于服务可用性范畴不在本文展开。安装层面我建议用 npm 全局安装时加上--save-exact或者确认安装路径在 PATH 里。如果安装后执行命令提示找不到检查 npm 的 global bin 目录是否在 PATH 中。Ubuntu 上通常是~/.npm-global/bin或 nvm 对应的 bin 目录。VS Code 配置 Claude Code 是另一个高频需求。热词里 “vscode配置claude code”“vscode接入claude code”“claude code for vs code” 都指向这个场景。核心思路是VS Code 里通过集成终端调用 Claude Code CLI或者安装对应的扩展。我的经验是先在系统终端里把 Claude Code 跑通再在 VS Code 的集成终端里验证最后才考虑扩展。顺序反了容易把问题归咎于扩展实际是底层 CLI 没配好。3.3 Codex 安装与配置项拼写检查Codex 的安装同样依赖 Node.js 环境。热词里 “codex安装”“codex安装教程”“codex安装 windows桌面版”“codex cli”“codex官网下载” 说明安装渠道和版本选择是大家关心的点。我的建议是优先用官方文档给出的安装方式通常是 npm 全局安装或者下载对应平台的二进制包。Windows 桌面版和 CLI 版是两回事桌面版适合图形化操作CLI 版适合脚本化和 tmux 集成。配置方面“codex is ignoring 1 unrecognized configuration setting. check for typos” 这个报错非常典型。Codex 的配置文件通常是 JSON 或 TOML 格式字段名大小写敏感拼写错误会导致整个配置项被忽略。排查方法是逐行对照官方文档的字段名确认没有多空格、没有用错下划线或驼峰。我自己的习惯是改完配置后先用工具自带的校验命令跑一遍没有校验命令就手动用 JSON 解析器验证格式。“codex无法加载组织设置” 通常和认证 token 或组织 ID 有关。检查环境变量里是否有正确的组织标识以及 token 是否过期。如果用的是第三方 API 接入比如 “codex接入deepseek”则需要确认 base URL 和模型名称是否匹配端点路径是否正确。热词里 “cc switch local proxy failed while handling codex endpoint /responses” 提示的是端点路径问题/responses这个路径是否被正确代理和转发需要检查本地代理配置。3.4 本地模型接入LM Studio 与第三方 API 的切换“claude code 调用lmstudio的本地模型” 和 “使用cc switch 接入 deepseek v4, qwen, glm等模型” 这两个热词代表了两种接入模式本地模型和第三方 API。本地模型的好处是离线可用、数据不出机器第三方 API 的好处是模型能力强、无需本地算力。openrig 的思路是两者都保留按需切换。LM Studio 的接入要点是启动 LM Studio 的本地服务端记下它监听的地址和端口通常是http://localhost:1234/v1这样的 OpenAI 兼容端点。然后在 Claude Code 或 Codex 的配置里把 base URL 指向这个地址模型名称填 LM Studio 里加载的模型标识。注意不是所有 CLI 工具都支持自定义 base URL需要确认版本和配置项。第三方 API 接入的要点是确认 API 的 base URL、认证方式、模型名称映射。有些工具要求模型名称和官方名称一致有些允许自定义别名。切换时最容易出错的是认证 header 的格式比如是Authorization: Bearer xxx还是x-api-key: xxx。我的做法是把这些信息记录在models.md里切换时复制粘贴避免记错。4. 实操过程与核心环节实现从零搭起一套可复用的 openrig4.1 环境初始化Ubuntu 上的完整准备流程假设你拿到一台干净的 Ubuntu 机器第一步是更新系统并安装基础工具。执行sudo apt update sudo apt upgrade -y然后安装 curl、git、build-essential 这些常用依赖。build-essential 很重要因为有些 npm 包需要编译原生模块没有编译器会直接安装失败。第二步是安装 nvm 和 Node.js LTS。用 curl 下载 nvm 安装脚本执行后 source~/.bashrc然后nvm install --lts。安装完成后确认node -v输出的是 LTS 版本号。第三步是安装 tmuxsudo apt install tmux -y然后创建一个测试会话确认能正常 attach 和 detach。第四步是创建 openrig 工作目录。mkdir -p ~/openrig在里面放配置文件。我通常还会建一个~/openrig/logs目录用来存放各个工具的启动日志方便排查。第五步是配置 shell 别名比如alias ccclaude、alias cxcodex减少输入负担。这些别名写在~/.bashrc或~/.zshrc里。提示每一步做完都验证一下不要一口气全装完再排查。装完 Node.js 就验证 node 和 npm装完 tmux 就验证会话装完 CLI 就验证版本号。这样出问题时能快速定位是哪一步引入的。4.2 Claude Code 的安装、认证与 VS Code 集成安装 Claude Code 时我用 npm 全局安装的方式。命令大致是npm install -g anthropic-ai/claude-code具体包名以官方文档为准。安装完成后执行claude --version确认。第一次运行claude会引导认证按提示完成浏览器授权或输入 API key。认证成功后在 tmux 的 claude window 里跑一次简单任务比如让它解释一段代码确认能正常返回。然后在 VS Code 里打开集成终端执行同样的命令确认环境变量和 PATH 在 VS Code 里也生效。如果 VS Code 里找不到命令检查 VS Code 的终端是否加载了 shell 配置有时候需要重启 VS Code 或者手动 source。VS Code 集成还有一个细节如果你用 Remote-SSH 连到 Ubuntu 开发机Claude Code 是跑在远程的认证和配置都在远程。这时候本地 VS Code 只是显示终端实际执行环境是远程。确认这一点可以避免“为什么本地装了却用不了”的困惑。4.3 Codex 的安装、配置与端点调试Codex 的安装同样先确认 Node.js 环境然后按官方方式安装。安装后第一步是跑codex --help看命令列表确认安装成功。第二步是配置认证通常是设置环境变量或者运行登录命令。第三步是配置模型接入点如果是官方服务用默认配置如果是第三方或本地修改 base URL 和模型名称。端点调试是重点。热词里 “cc switch local proxy failed while handling codex endpoint /responses” 说明代理层可能有问题。我的排查顺序是先确认 Codex 直连能否工作再引入代理先确认端点路径是否正确再检查认证 header先看日志里实际请求的 URL再对比配置里的 URL。很多时候问题出在 URL 拼接上比如 base URL 末尾多了或少了斜杠导致最终路径变成//responses或/v1/responses。配置项拼写检查我通常用一个小脚本把配置文件里的 key 提取出来和官方文档的 key 列表做对比。没有脚本就手动核对重点看驼峰和下划线的区别以及是否有拼写错误。Codex 对未知配置项的处理是忽略并警告所以看到 “unrecognized configuration setting” 不要慌按提示找到那一行改掉即可。4.4 tmux 会话组织与多模型切换的日常操作我的日常操作流程是这样。早上到工位tmux attach -t openrig恢复会话。如果会话不存在tmux new -s openrig新建。然后Ctrlb c创建三个 window分别命名。在 claude window 里跑 Claude Code在 codex window 里跑 Codex在 local window 里跑 LM Studio 的服务端或者查看本地模型日志。切换模型时我不改全局配置而是在对应的 window 里 source 不同的 env 文件。比如要切到本地模型就在 claude window 里source ~/openrig/claude-local.env然后重启 Claude Code。要切回官方服务就source ~/openrig/claude-official.env。这样两个 window 可以同时用不同的模型互不影响。tmux 的快捷键需要熟悉几个Ctrlb c新建 windowCtrlb n下一个 windowCtrlb p上一个 windowCtrlb ddetachCtrlb [进入 scroll 模式查看历史输出。这些操作花十分钟练一下之后效率提升非常明显。5. 常见问题与排查技巧实录那些热词背后的真实坑5.1 安装类问题速查表报错关键词可能原因排查动作解决方向node.js v24.21.0 is not yet released指定了不存在或未发布的版本确认版本号是否真实存在改用--lts或已发布版本error installing网络、权限或编译依赖缺失看完整日志确认失败步骤补依赖、换源、用管理员权限command not foundPATH 未包含 CLI 安装目录which和echo $PATH把 npm global bin 加入 PATH组织已禁用订阅访问账号权限或组织策略限制确认账号类型和组织设置换个人账号或联系管理员区域不可用提示服务可用性范围限制确认服务支持范围属于服务侧限制不在本地解决这张表里的每一行我都在实际环境里遇到过。最容易被忽略的是 PATH 问题因为安装过程看起来成功了但执行命令就是找不到。这时候不要急着重装先npm bin -g看全局 bin 目录在哪里再确认它在 PATH 里。5.2 配置类问题的排查思路配置类问题的核心原则是先确认格式再确认字段最后确认值。格式问题包括 JSON 少逗号、TOML 缩进错误、YAML 冒号后没空格。字段问题包括拼写错误、大小写错误、用了废弃字段。值的问题包括 URL 写错、端口写错、模型名称不匹配。“codex is ignoring 1 unrecognized configuration setting” 这个报错我的处理流程是打开配置文件找到报错提示的那一行对照官方文档确认字段名。如果文档里没有这个字段说明是废弃字段或者拼写错误删掉或改正。如果文档里有但拼写不同改成文档里的写法。改完保存重启 Codex确认报错消失。“cc switch local proxy failed while handling codex endpoint /responses” 这个报错重点检查代理配置。确认代理是否在运行确认代理规则是否匹配/responses路径确认转发目标地址是否正确。如果代理工具支持日志打开日志看实际转发的 URL 和返回状态码。很多时候是代理规则写得太宽或太窄导致请求没被正确处理。5.3 模型接入类问题的经验总结本地模型接入最常见的问题是端点不兼容。LM Studio 提供 OpenAI 兼容端点但不是所有 CLI 工具都按 OpenAI 格式发请求。如果工具要求特定的请求格式而本地服务端不支持就会报错。这时候要么换支持的工具版本要么在中间加一层适配。第三方 API 接入最常见的问题是认证和模型名称。认证方面确认 header 名称和格式模型名称方面确认 API 提供方要求的名称和你在配置里写的一致。有些 API 要求模型名称带前缀有些不带这个必须按文档来。还有一个容易被忽略的点超时设置。本地模型如果加载慢默认超时可能不够导致请求失败。第三方 API 如果网络延迟高也可能超时。检查配置里是否有超时字段适当调大。这个细节在文档里往往不显眼但实际影响很大。5.4 我踩过的三个真实坑第一个坑Node.js 版本混用。我一开始用系统自带的 Node.js后来装了 nvm结果 PATH 里两个版本打架npm 全局包装到了错误的位置。解决方法是清理系统 Node.js统一用 nvm 管理并在 shell 配置里确保 nvm 的初始化在 PATH 设置之后。第二个坑tmux 会话里的环境变量不更新。我在 tmux 里改了 env 文件并 source但新开的 window 没有继承。原因是 tmux 的环境变量在会话创建时就固定了。解决方法是 detach 后重新 attach或者在 tmux 配置里开启update-environment。这个坑让我浪费了一个下午后来养成习惯改环境变量后重启 tmux 会话。第三个坑配置文件里的注释导致解析失败。有些工具的配置文件不支持注释我加了//注释后整个文件解析失败但报错信息很模糊。解决方法是配置文件里不写注释把说明写在单独的文档里。这个教训很基础但确实容易犯。6. 关于 openrig 这套思路的延伸与个人体会openrig 这个标题给我的最大启发是把 AI 编码助手当成一套需要工程化管理的工具链而不是随手装随手用的玩具。Node.js 是底座tmux 是会话层统一配置是管理层Claude Code 和 Codex 是具体的执行器。这套结构搭好之后换模型、加工具、排查问题都有章可循。我个人在实际操作中的体会是不要追求一次配到完美先把最小可用链路跑通。Node.js 装好tmux 跑起来一个 CLI 工具能正常对话这就够了。然后再逐步加第二个工具、加本地模型、加第三方 API。每加一个环节验证一次记录一次配置。这样即使出问题也知道是哪一步引入的。最后分享一个小技巧把常用的启动命令写成 shell 脚本比如start-claude.sh、start-codex.sh脚本里包含 source env 文件和启动命令。这样每次启动只需要执行一个脚本减少手动操作带来的错误。脚本放在~/openrig/scripts/下配合 tmux 的send-keys还能实现一键启动整套环境。这个做法看起来简单但长期用下来节省的时间和减少的烦躁感非常可观。