1. 从“openrig”说起一个把 Claude Code 和 Codex 装进同一台机器的实战思路第一次看到 “openrig” 这个词我下意识把它拆成了 “open” 和 “rig” 两部分。rig 在工程语境里指的是“装配、搭台子”open 则暗示这套东西是开放的、可拆装的。合在一起它描述的其实是一件很朴素的事把散落在各处的 AI 编码工具组装成一套自己能完全掌控的工作台。而围绕它出现的一连串热搜词——Claude Code、Codex、Node.js、tmux——恰好勾勒出了这套工作台的完整轮廓。我接触 Claude Code 和 Codex 这类命令行 AI 编码助手有一段时间了。最开始我也踩过不少坑Node.js 版本装错导致命令跑不起来tmux 会话没配好导致长任务一断网就前功尽弃本地模型和云端模型来回切换时配置改得一团乱。后来我慢慢意识到真正让人头疼的从来不是某一个工具本身而是这些工具之间的“装配关系”。openrig 这个标题之所以值得单独拿出来聊就是因为它指向的正是这层装配逻辑。这篇文章适合谁看如果你已经装过 Claude Code 或者 Codex但总觉得用起来磕磕绊绊如果你打算在 Ubuntu 或者 Windows 上搭一套稳定的 AI 编码环境如果你想把本地模型和第三方 API 都接进来统一管理——那这篇内容基本就是为你写的。我会从整体设计思路讲起把 Node.js 环境、tmux 会话管理、Claude Code 与 Codex 的安装配置、本地模型接入、常见报错排查这些环节一个个拆开尽量把每一步背后的“为什么”也讲清楚。全程按我自己的实操顺序来能直接抄作业的地方我会给到具体命令和参数。需要先说明一点下面涉及的所有工具、命令和配置都是基于公开可获取的通用软件和常见实践整理的。不同版本之间会有差异具体以你实际安装时的官方说明为准。2. 整体设计与思路拆解为什么是这套组合2.1 为什么把 Node.js 当作地基Claude Code 和 Codex 这两类命令行工具绝大多数都是基于 Node.js 生态分发的。你去看它们的安装方式基本都绕不开 npm 或者 npx。这就决定了 Node.js 是整个工作台的地基地基没打好上面盖什么都是歪的。我见过太多人卡在第一步随手从某个渠道下了个 Node.js 装上结果版本要么太老要么是个还没正式发布的版本。热搜里那条 “error installing 24.21.0: node.js v24.21.0 is not yet released or is not available” 就是典型的版本踩坑——你指定了一个尚未发布的版本号包管理器自然找不到。我的建议很明确优先选 LTS长期支持版本而不是追最新的奇数版本。LTS 版本经过更长时间的验证和各类工具的兼容性最稳。Node.js 在这里扮演的角色你可以理解成“发动机”。Claude Code、Codex 这些工具是装在发动机上的各种配件配件再花哨发动机不稳整台机器就抖。所以我在搭任何 AI 编码环境之前第一件事永远是确认 Node.js 版本而不是急着装工具。2.2 tmux 解决的是什么问题很多人会问我就跑个命令行工具为什么要扯上 tmux答案藏在“长任务”这三个字里。AI 编码助手经常要处理耗时较长的任务比如让它读一个大仓库、跑一轮重构、或者持续对话。如果你直接在普通终端里跑一旦网络抖动、SSH 断连、或者你不小心关了窗口这个进程就没了之前积累的上下文可能全部丢失。tmux 的价值就在于它把会话和终端窗口解耦了——窗口关了会话还在后台跑你重新连上来attach 回去一切照旧。这就像你炖一锅汤tmux 是那个一直放在灶上的锅你人可以离开厨房去干别的回来汤还是热的。对于需要长时间运行的 AI 编码任务来说这个特性几乎是刚需。所以在这套 openrig 的装配思路里tmux 不是可选项而是让整个工作流“抗打断”的关键一环。2.3 Claude Code 与 Codex 为什么要放在一起Claude Code 和 Codex 定位相近都是命令行里的 AI 编码助手但它们的模型来源、配置方式、擅长场景各有侧重。有人只用其中一个也有人两个都装按任务类型切换。把它们放在同一台机器上好处是你可以根据手头的活儿灵活选择坏处是配置容易互相干扰——尤其是当你还接了本地模型或者第三方 API 的时候。我的思路是统一环境隔离配置。Node.js 和 tmux 是共享的基础设施两个工具都用同一套但各自的配置文件、API 端点、模型选择要分开放互不污染。这样既省去了重复搭环境的麻烦又避免了“改了 A 把 B 弄坏”的尴尬。热搜里那条 “codex is ignoring 1 unrecognized configuration setting. check for typos or d” 就是配置写错位置的典型症状——工具读到了它不认识的字段只能忽略然后行为就不符合预期了。2.4 本地模型与第三方 API 的接入考量热搜里还有几条很关键“claude code 调用 lmstudio 的本地模型”、“codex 接入 deepseek”、“使用 cc switch 接入 deepseek v4, qwen, glm 等模型”。这说明大家的需求已经从“能用”进化到了“按需切换模型”。本地模型的好处是数据不出本机、响应可控、不依赖外部网络第三方 API 的好处是模型能力强、开箱即用。理想状态是两者都能接随时切换。但这里有个绕不开的现实不同工具对“自定义端点”的支持程度不一样有的原生支持有的需要借助中间层。所以我在设计这套工作台时会把“模型接入层”单独拎出来考虑而不是把它和工具本身混在一起。这样将来换模型、加模型改动面最小。3. 核心细节解析与实操要点环境搭建的每一步3.1 Node.js 安装版本选择与验证先说安装。Ubuntu 上我一般用 NodeSource 的源或者 nvm 来管理版本Windows 上直接用官网的 LTS 安装包。这里重点讲版本选择的逻辑。Node.js 的版本号分三类偶数版本是 LTS奇数版本是当前版Current。LTS 版本会获得长期维护适合生产环境当前版包含最新特性但可能不稳定。对于 AI 编码工具这种依赖链比较长的场景我强烈建议用 LTS。截至我写这篇内容时比较稳妥的选择是 20.x 或 22.x 的 LTS 版本。安装完成后务必验证node -v npm -v两条命令都要能正常输出版本号。如果node -v报错或者输出了一个奇怪的版本说明 PATH 没配好或者装了多个版本互相打架。Windows 上这种情况尤其常见因为安装包和某些包管理器可能各装了一份。提示如果你之前装过旧版本建议先彻底卸载再装新版本避免残留的全局包和新版本冲突。用 nvm 的话切换版本后记得重新安装全局工具。3.2 tmux 的安装与基础会话管理Ubuntu 上装 tmux 很简单sudo apt update sudo apt install tmuxWindows 上原生没有 tmux通常的做法是在 WSL 里用或者用类似的终端复用方案。如果你主要在 Windows 桌面环境工作又想要会话保持能力可以考虑在 WSL 里跑整套环境这样 tmux 就能正常用了。tmux 的核心操作就几个记住就够日常用了tmux new -s work新建一个叫 work 的会话tmux ls列出所有会话tmux attach -t work重新连回 work 会话Ctrlb然后按d从会话里脱离但会话继续在后台跑我的习惯是给每个长期任务开一个独立会话比如claude一个、codex一个互不干扰。这样即使某个任务卡住了也不影响另一个。3.3 Claude Code 的安装与首次配置Claude Code 的安装通常通过 npm 全局安装npm install -g anthropic-ai/claude-code装完之后第一次运行会引导你做认证和基础配置。这里有几个点要注意。第一认证方式。不同版本、不同地区的可用性会有差异热搜里那条 “note: claude code might not be available in your country” 和 “your organization has disabled claude subscription access” 都指向了可用性和权限问题。遇到这类提示先确认你的账号状态和所在环境的支持情况不要盲目反复重试。第二配置文件的位置。Claude Code 一般会在用户目录下生成配置具体路径随版本变化。改配置之前先备份改完出问题能快速回滚。第三和 VS Code 的集成。热搜里 “vscode 配置 claude code”、“claude code for vs code” 出现频率很高。如果你习惯在 VS Code 里工作装好对应的扩展后可以在编辑器内直接调用省去切终端的麻烦。但要注意扩展版本和 CLI 版本的匹配版本错配是很多“明明装了却用不了”问题的根源。3.4 Codex 的安装与配置要点Codex 的安装路径和 Claude Code 类似也是走 npm 生态。装完之后同样需要配置认证和模型端点。热搜里 “codex 安装 windows 桌面版”、“codex 安装 csdn”、“codex 官网下载” 说明很多人在找安装入口。我的建议是认准官方渠道不要从来源不明的第三方站点下载安装包一是版本可能被改过二是可能夹带不需要的东西。配置方面Codex 对配置文件的格式比较敏感。那条 “codex is ignoring 1 unrecognized configuration setting” 就是明证——你写了一个它不认识的字段它不会报错只会默默忽略然后你就纳闷为什么设置没生效。所以改配置时字段名一定要对照官方文档逐个核对宁可少写也不要乱写。3.5 本地模型接入以 LM Studio 为例把 Claude Code 接到 LM Studio 的本地模型上核心是让工具把请求发到本机的某个端口而不是默认的云端端点。LM Studio 启动本地服务后会暴露一个兼容常见 API 格式的地址通常是http://localhost:1234这类。接入的关键在于配置里的端点地址和模型名称要写对。模型名称必须和 LM Studio 里加载的模型标识一致写错了就会报找不到模型。另外本地模型的上下文长度、并发能力通常不如云端长任务容易超时这时候 tmux 的价值又体现出来了——超时了可以重试会话不会丢。3.6 第三方 API 接入与多模型切换热搜里 “使用 cc switch 接入 deepseek v4, qwen, glm 等模型” 反映了一个很实际的需求不想被单一模型绑死想按任务切换。cc switch 这类工具的思路是在多个模型配置之间做切换让你不用手动改配置文件。我的做法是维护一份“模型清单”每个模型对应一组端点、密钥、模型名。切换时只改指向不动其他配置。这样即使某个模型服务临时不可用也能快速切到备选不至于整个工作流停摆。注意无论接本地模型还是第三方 API密钥都不要硬编码在会提交到版本库的文件里。用环境变量或者独立的、被忽略的配置文件来存。4. 实操过程与核心环节实现从零搭起一套可用的工作台4.1 环境准备清单与顺序我把整套流程拆成了一条清晰的顺序按这个顺序走基本不会出现“装到一半发现前置没做”的情况确认操作系统和终端环境Ubuntu 原生终端或 Windows WSL安装并验证 Node.js LTS 版本安装 tmux 并熟悉基础会话操作安装 Claude Code完成认证安装 Codex完成认证配置本地模型端点可选配置第三方 API 与多模型切换可选联调测试逐个验证这个顺序的逻辑是先地基Node.js再容器tmux再主体工具最后接外部模型。每一步都建立在前一步可用的基础上出问题容易定位。4.2 Node.js 与 tmux 的落地操作Ubuntu 上用 nvm 管理 Node.js 的完整流程大致是这样# 安装 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用 nvm 的好处是版本切换方便将来某个工具需要特定 Node.js 版本时一条命令就能切过去不用卸载重装。tmux 装好后我建议先建一个专门的工作会话tmux new -s openrig之后所有和这套工作台相关的操作都在这个会话里进行。需要离开时按Ctrlb再按d脱离回来时tmux attach -t openrig接上。4.3 Claude Code 安装与终端命令执行验证安装命令前面给过了。装完后我一般会做一次“能不能直接执行终端命令”的验证因为热搜里 “claude code 如何直接执行终端命令” 是个高频疑问。验证方法是在 Claude Code 的交互界面里让它执行一个无害的命令比如列出当前目录文件。如果它能正确调用终端并返回结果说明工具和系统终端的衔接是通的。如果不行通常是权限或者配置里禁用了命令执行需要去配置里放开。这一步很关键因为 AI 编码助手的核心价值之一就是能替你跑命令、看结果、再决策。这个链路不通它就退化成了一个纯聊天工具。4.4 Codex 安装与登录排障Codex 安装后第一次登录可能会遇到 “codex 无法加载组织设置”、“codex 登录” 相关的问题。我的排查顺序是确认网络能正常访问认证服务确认账号状态正常没有权限限制确认 CLI 版本是最新的旧版本可能认证协议已经变了清理本地缓存的认证信息重新登录这四步能解决绝大多数登录类问题。如果还不行去看工具的日志输出日志里通常有更具体的错误码。4.5 本地模型联调从配置到跑通以 LM Studio 为例联调步骤是在 LM Studio 里加载一个模型启动本地服务记下服务地址和模型标识在 Claude Code 或 Codex 的配置里把端点指向本地服务地址把模型名改成 LM Studio 里的模型标识发一条测试请求看是否正常返回这里最常见的坑是端口被占用或者服务没真正启动。先用浏览器或者 curl 访问一下本地服务地址确认它活着再去配工具。顺序反了的话你会分不清是工具的问题还是服务的问题。4.6 多模型切换的配置组织方式我维护的模型清单大概长这样示意具体字段以工具文档为准模型来源端点类型适用场景备注本地 LM Studio本机端口数据敏感、离线上下文有限第三方 API A云端复杂重构需密钥第三方 API B云端快速问答需密钥切换时只改“当前使用”的指向其他配置不动。这样切换成本最低也最不容易出错。把这张表放在手边比每次翻文档快得多。5. 常见问题与排查技巧实录那些热搜里的报错到底怎么回事5.1 安装类报错速查报错关键词可能原因处理思路node.js v24.21.0 is not yet released指定了未发布版本改用 LTS 版本号error installing网络或源问题换源、检查网络、重试安装后命令找不到PATH 未配置检查环境变量重开终端安装类问题九成出在版本和路径上。我的经验是装之前先查清楚目标工具要求的 Node.js 版本范围装之后立刻用node -v和npm -v验证别等到装工具时才暴露问题。5.2 配置类报错速查报错关键词可能原因处理思路unrecognized configuration setting字段名拼写错误或不被支持对照文档逐字核对无法加载组织设置权限或认证问题检查账号状态重新登录配置改了不生效改错了文件或位置确认配置文件路径配置类问题的核心是“你以为改对了其实没改对”。我养成的习惯是每次改配置前先备份改完立刻做一次最小验证确认生效了再继续。这样一旦出问题能马上定位到是哪次改动引起的。5.3 运行类报错速查报错关键词可能原因处理思路长任务中途断掉终端会话丢失用 tmux 保持会话本地模型请求超时上下文过长或性能不足缩短输入换更小模型模型切换后行为异常端点或模型名不匹配核对配置重启工具运行类问题里tmux 能解决一大半“断连”相关的困扰。剩下的多半是模型配置不匹配核对端点、密钥、模型名这三样基本能覆盖。5.4 我踩过的几个真实坑第一个坑是 Node.js 装了多个版本。系统里同时存在 apt 装的、nvm 装的、还有某个安装包自带的结果node -v显示的版本和我以为的不一样工具跑起来各种诡异。后来统一用 nvm 管理把其他的清理掉问题消失。第二个坑是 tmux 会话命名太随意。有一次开了好几个会话名字都差不多attach 的时候接错了把正在跑的任务给中断了。从那以后我坚持用有意义的名字比如按任务类型命名。第三个坑是本地模型和云端模型混用时忘了改模型名。端点指向本地模型名还是云端的结果请求发出去一直报错。这个错误很低级但排查起来费时间因为报错信息不一定直白。现在我切换模型时端点和模型名一定成对修改改完立刻测一条。5.5 让工作台更稳的几个习惯每次动配置前先备份出问题能秒回滚长任务一律放 tmux 里跑不裸跑模型清单单独维护切换只改指向装完任何工具立刻做最小验证别攒着一起测报错先看日志别急着搜日志里的信息往往比搜索结果准这些习惯看着琐碎但真到了出问题的时候能帮你省下大量时间。AI 编码工具本身在快速迭代配置和接口随时可能变唯一能让你稳住的就是这套“可回滚、可验证、可切换”的工作方式。6. 关于 openrig 这套思路的延伸想法把 Claude Code、Codex、Node.js、tmux 这几样东西装配到一起本质上是在给自己搭一个“不依赖单一工具、不害怕环境变化”的编码工作台。openrig 这个标题给我的启发是与其追着每个工具的最新教程跑不如把底层的装配逻辑吃透。工具会换模型会更新但“地基稳、容器牢、配置清、可切换”这套原则不会过时。我个人的体会是真正拉开效率差距的往往不是用了多强的模型而是环境是否顺手、切换是否顺畅、出问题是否能快速恢复。一个配置混乱的环境再强的模型也发挥不出来一个装配得当的工作台哪怕用的是普通模型也能稳定产出。后续如果还想继续扩展我会考虑的方向是把这套工作台的配置做成可版本管理的模板换机器时一键还原再就是把模型清单和切换逻辑进一步自动化减少手动改配置的次数。这些都属于锦上添花前提是前面那套基础装配已经跑通、跑稳。