1. 从 openrig 这个名字说起它到底想解决什么问题第一次看到openrig这个词我脑子里蹦出来的不是某个具体工具而是一种把散装零件拼成一台能跑的工作台的感觉。rig 在英文里本意是装配、索具、成套设备在开发圈里常被用来指代一套完整的工作环境或者测试台架。前面加个 open意思就很直白了——一套开放的、可自由组合的开发环境装配方案。结合热搜词里高频出现的 Claude Code、Codex、Node.js、tmux 这几个关键词我基本能判断出 openrig 瞄准的是同一类人群那些想在本地或者远程服务器上把 AI 编程助手Claude Code、Codex CLI 这类终端智能体跑起来并且希望这套环境稳定、可复用、能长期维护的开发者。这类人通常已经过了装个软件点下一步的阶段他们真正头疼的是多个 AI 编程工具怎么共存、Node.js 版本怎么管、终端会话断了任务怎么办、本地模型怎么接进来、代理配置冲突怎么排查。我自己在这条路上踩过的坑不算少。最早的时候我是在一台 Ubuntu 服务器上装 Claude Code装完发现 Node.js 版本不对升完 Node.js 又发现 tmux 会话里环境变量没继承折腾到半夜。后来 Codex CLI 出来我又想让它和 Claude Code 共用一套配置结果两个工具抢同一个端口报了一堆cc switch local proxy failed while handling codex endpoint /responses之类的错。这些经历让我意识到单装一个工具不难难的是把它们组织成一个rig——一套有秩序的工作台。openrig 这个概念的价值就在这里。它不是又一个 AI 编程工具而更像是这套工作台的装配说明书或者脚手架约定。它要回答的问题是当你要同时使用 Claude Code、Codex CLI、本地模型、远程终端会话时目录怎么放、版本怎么锁、会话怎么保活、配置怎么隔离、出问题怎么定位。这篇文章我就按这个思路把 openrig 这类环境装配方案的核心逻辑、实操步骤和踩坑经验完整拆一遍。不管你是刚听说 Claude Code 想入门还是已经在用 Codex 但被配置问题折磨应该都能从里面找到能直接抄作业的部分。2. 装配一套 AI 编程工作台先想清楚这几件事2.1 为什么不能装完就用而要谈装配很多人对 AI 编程工具的理解停留在下载、安装、登录、开聊。这个流程在单工具、单机器的场景下确实够用。但一旦你的使用场景变成下面任意一种裸装就会立刻暴露问题你同时用 Claude Code 和 Codex CLI两者都依赖 Node.js但要求的版本区间不一样你在远程服务器上跑长任务SSH 一断正在执行的智能体会话就没了你想让 Claude Code 调用本地 LM Studio 的模型但默认配置指向云端改配置又怕影响其他工具你团队里几个人共用一台开发机每个人的 API 配置、模型偏好都不一样互相覆盖。这些问题的共同点是它们都不是工具本身的 bug而是环境组织的问题。openrig 这类方案的核心思路就是把环境当成一个需要设计的系统而不是一堆随手装上的软件。你要提前决定Node.js 用哪个版本管理方案、终端会话用什么保活、配置文件放在哪、多个工具的配置怎么隔离。这些决定做对了后面 90% 的诡异报错都不会出现。2.2 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 这一关。这不是偶然——Claude Code 和 Codex CLI 都是 Node.js 生态的工具Node.js 版本不对后面全盘皆输。我的建议很明确不要用系统包管理器直接装 Node.js。apt install nodejs或者从官网下载 pkg 双击安装都会把 Node.js 钉死在一个全局版本上。等你需要切换版本时就得卸载重装非常痛苦。正确做法是用版本管理器主流选择是nvm或者fnm。nvm 更老牌、资料多fnm 更快、用 Rust 写的两者都行。安装 nvm 的标准流程以 bash 为例curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash装完之后要重新加载 shell 配置然后验证command -v nvm nvm --version接下来是关键一步——装 LTS 版本而不是最新版。热搜里那个node.js v24.21.0 is not yet released的报错本质就是有人指定了一个还不存在的版本号。稳妥做法是nvm install --lts nvm use --lts nvm alias default lts/*nvm alias default这行很重要它保证你新开一个终端时自动用 LTS 版本而不是每次手动nvm use。我见过太多人装完 nvm 忘了设默认结果新开 tmux 窗口时 Node.js 又变回系统版本然后 Claude Code 报一堆模块找不到的错。提示如果你在服务器上装 nvm注意它默认写进~/.bashrc。如果你用的是 zsh得手动把那段配置挪到~/.zshrc否则nvm命令根本找不到。2.3 tmux 不是可选项而是长任务的保险绳热搜词里tmux和 Claude Code、Codex 并列出现这个信号很明确真正在用这些工具干活的人都在用 tmux。原因很简单——AI 编程助手经常要跑几分钟甚至几十分钟的任务比如让它读一个大仓库、重构一个模块、跑一轮测试。如果你直接在 SSH 会话里跑网络一抖会话断了任务就死了而且你连它跑到哪一步都不知道。tmux 解决的就是这个问题。它把终端会话和你的 SSH 连接解耦SSH 断了tmux 里的进程照跑你重新连上来tmux attach就能看到完整输出。这是 openrig 这类工作台方案里不可或缺的一环。基础用法就几个命令但每个都有讲究tmux new -s work # 新建名为 work 的会话 tmux ls # 列出所有会话 tmux attach -t work # 重新接入 work 会话 tmux kill-session -t work # 结束会话在 tmux 会话内部Ctrlb是前缀键然后d是 detach脱离但不结束c是新建窗口%是左右分屏是上下分屏。我个人的习惯是一个项目一个 tmux 会话会话里第一个窗口跑 Claude Code第二个窗口跑 Codex第三个窗口留给 shell 做杂活。这样切换起来非常快而且每个工具的上下文互不干扰。有个细节很多人不知道tmux 会话里的环境变量是在会话创建时快照的。如果你先开了 tmux再在外部nvm use切换了 Node.js 版本tmux 里还是老版本。所以正确顺序是先切好 Node.js 版本再开 tmux。或者干脆在 tmux 里重新source ~/.bashrc。3. Claude Code 与 Codex 的安装路径与配置隔离3.1 两个工具的安装方式差异决定了配置怎么放Claude Code 和 Codex CLI 虽然都是终端 AI 编程工具但安装和配置的哲学不太一样理解这个差异对装配工作台很关键。Claude Code 官方推荐用 npm 全局安装npm install -g anthropic-ai/claude-code装完之后它的配置主要放在用户目录下的.claude文件夹里包括settings.json、项目级的CLAUDE.md等。它的设计偏向一个用户一套配置项目级覆盖。Codex CLI 的安装方式更灵活可以用 npm也可以用官方提供的安装脚本。它的配置通常放在~/.codex目录下配置文件格式和 Claude Code 不同。热搜里codex is ignoring 1 unrecognized configuration setting. check for typos这个报错就是配置文件里写了它不认识的字段说明 Codex 对配置格式的校验比较严格。这里就引出一个装配原则两个工具的配置目录天然是分开的不要试图让它们共用一份配置。我见过有人为了统一管理把两个工具的 API key 写进同一个环境变量文件结果 Claude Code 读到了 Codex 的配置格式直接报错。正确做法是各管各的需要共享的部分比如 API 端点通过环境变量传递而不是共享配置文件。3.2 环境变量是配置隔离的利器但要小心作用域环境变量是隔离配置最干净的手段。比如你想让 Claude Code 走某个自定义端点可以设export ANTHROPIC_BASE_URLhttps://your-endpoint.example.com export ANTHROPIC_API_KEYyour-keyCodex 那边类似用OPENAI_API_KEY之类的变量。但这里有个坑如果你把这些export写在~/.bashrc里它们会对所有终端会话生效包括你不想让它们生效的场景。更麻烦的是如果你在 tmux 里改了环境变量新开的窗口可能继承的是旧值。我的做法是给每个工具写一个独立的启动脚本比如~/bin/start-claude.sh和~/bin/start-codex.sh脚本里先设好环境变量再启动工具。这样每个工具的运行时环境是干净的互不污染。脚本大概长这样#!/bin/bash export ANTHROPIC_BASE_URLhttps://your-endpoint.example.com export ANTHROPIC_API_KEYyour-key exec claude $用exec是为了让脚本进程被工具进程替换避免多一层 shell 嵌套。这个细节在 tmux 里尤其重要否则你 detach 的时候可能留下僵尸进程。3.3 本地模型接入LM Studio 与自定义端点的配置要点热搜里claude code 调用lmstudio的本地模型这个词说明不少人在尝试本地模型接入。这个需求很合理——有些代码不方便发到云端或者你就是想省 API 费用。但本地模型接入有几个硬性前提不满足的话配了也白配。第一本地模型服务必须提供兼容的 API 接口。LM Studio 可以启动一个本地 server暴露类似 OpenAI 格式的接口。第二Claude Code 和 Codex 对接口格式的要求不同Claude Code 期望的是 Anthropic 风格的接口Codex 期望的是 OpenAI 风格的接口。如果你用 LM Studio 同时服务两个工具可能需要它同时暴露两种格式或者用一层转换。配置的时候端点地址通常是http://localhost:1234/v1这种形式。注意localhost在容器或者远程场景下可能不对得换成实际 IP。我踩过一次坑在 Docker 里跑 Claude Code配置写localhost:1234结果连的是容器自己的 localhost不是宿主机的 LM Studio。后来改成宿主机的局域网 IP 才通。注意本地模型的上下文窗口通常比云端模型小很多。Claude Code 这类工具默认会塞进去大量上下文项目结构、文件内容本地模型很容易爆窗口。接入本地模型后建议在配置里调小上下文预算或者用更精简的项目描述。4. 那些让人抓狂的报错其实都有迹可循4.1cc switch local proxy failed这类代理冲突的根因热搜里cc switch local proxy failed while handling codex endpoint /responses这个报错信息量很大。拆开看cc switch大概率是某个用于切换 Claude Code 配置的工具local proxy说明它起了一个本地代理handling codex endpoint /responses说明这个代理在处理 Codex 的/responses端点时失败了。这类问题的根因通常是多个工具或配置切换器抢同一个本地端口或者代理规则互相覆盖。比如你先用 cc switch 起了一个代理监听 8080然后 Codex 也想用 8080冲突就来了。或者 cc switch 的代理规则只认 Claude 的端点格式遇到 Codex 的/responses路径不知道怎么转发直接报错。排查这类问题的顺序我总结成三步先看端口占用。lsof -i :8080或者netstat -tlnp | grep 8080确认到底谁在监听。再看代理配置。把 cc switch 的配置和 Codex 的配置都打开对比端点地址和端口看有没有重叠。最后看日志。代理工具一般会打日志日志里会写清楚它在转发哪个请求时失败失败原因是什么。解决方式通常是给不同工具分配不同端口或者干脆不用中间代理让每个工具直连自己的端点。代理层越多出问题的概率越大这是我在装配工作台时的一条铁律。4.2organization has disabled claude subscription access的应对思路热搜里your organization has disabled claude subscription access for claude code这个报错本质是账号权限问题不是技术问题。它说明你用的账号所属组织在管理后台关闭了 Claude Code 的访问权限。这种情况你自己在本地怎么折腾都没用得找组织管理员开通或者换一个个人账号。我想强调的是遇到这类报错不要一头扎进技术排查。先判断它是环境问题还是权限问题。权限问题的特征是报错信息里出现 organization、subscription、access、disabled 这类词而且换台机器、重装工具都一样报。识别出来之后直接走账号流程能省下大量瞎折腾的时间。4.3codex is ignoring 1 unrecognized configuration setting的排查方法这个报错相对友好它明确告诉你配置文件里有一个它不认识的设置项。Codex 的配置校验比较严格多一个字段就警告。排查方法很直接打开 Codex 的配置文件通常是~/.codex/config.toml或类似路径。逐行看找出可能是拼写错误或者过时的字段。常见的是把model拼成modle或者用了旧版本才支持的字段。注释掉可疑行重启 Codex看警告是否消失。我建议养成一个习惯改配置文件前先备份改完用工具自带的校验命令如果有先验一遍。Codex 这类工具迭代快配置字段会变网上抄来的配置很可能已经过时。以官方文档为准别迷信博客里的老配置。5. 把工作台跑顺的实操细节与经验5.1 目录结构约定让环境可复现一套好的 openrig 装配方案目录结构应该是清晰且可复现的。我自己的约定是这样的~/ai-rig/ ├── bin/ # 各工具的启动脚本 │ ├── start-claude.sh │ └── start-codex.sh ├── configs/ # 各工具的配置备份 │ ├── claude/ │ └── codex/ ├── projects/ # 实际项目 └── notes/ # 踩坑记录这个结构的好处是换机器时把bin和configs拷过去基本就能恢复环境。notes目录尤其重要每次遇到报错、解决之后把现象和解决方案记下来。我现在的 notes 里已经攒了几十条很多问题第二次遇到时直接查笔记几分钟搞定。5.2 版本锁定别让自动更新毁掉你的环境Node.js 用 nvm 锁 LTS这个前面说了。工具本身也要注意版本。Claude Code 和 Codex 都在快速迭代新版本可能引入不兼容的配置变更。我的做法是生产用的环境锁定一个验证过的版本不盲目追新。npm 全局包可以用npm install -g anthropic-ai/claude-codex.y.z指定版本。如果哪天想升级先在一个独立的 tmux 会话里试确认没问题再切过去。这个习惯帮我避免了好几次升级完工具跑不起来又得回滚的尴尬。5.3 会话保活与日志留存tmux 解决了会话保活但日志留存还得单独做。Claude Code 和 Codex 的输出默认只在终端里会话结束就没了。我的做法是在 tmux 里用script命令或者tee把输出同时写到文件claude 21 | tee ~/ai-rig/logs/claude-$(date %Y%m%d-%H%M).log这样即使会话崩了日志还在排查问题时有据可查。日志文件记得定期清理不然几个月下来能占好几个 G。5.4 多工具共存的资源分配同时跑 Claude Code 和 Codex 时注意资源占用。两个工具如果都在跑大任务CPU 和内存会吃紧尤其是本地模型场景。我的经验是同一时间只让一个工具跑重任务另一个保持空闲或者只做轻量查询。tmux 分屏看着方便但别真的让两个智能体同时啃同一个大仓库它们会互相拖慢而且输出混在一起很难看。6. 从 openrig 这个思路延伸出去的几点体会openrig 这个词本身没有官方定义但从它关联的热词和场景来看它代表的是一种把 AI 编程工具当系统工程来对待的态度。我用了大半年这类工具最大的体会是工具本身的能力差距远小于环境装配水平带来的差距。同样是用 Claude Code有人天天被报错折磨有人能稳定跑一整天任务差别就在环境有没有设计好。Node.js 版本管理、tmux 会话保活、配置隔离、日志留存、版本锁定这几件事看起来琐碎但每一件都直接决定你的工作台能不能长期稳定运行。我建议刚入门的朋友不要急着追新工具先把这套基础打牢。等你的环境稳了再去尝试本地模型接入、多工具协同这些进阶玩法会顺畅得多。最后分享一个我自己的小习惯每次环境出问题解决之后我都会问自己一句这个问题下次怎么提前避免。答案往往不是某个具体命令而是某个约定——比如以后所有工具都用启动脚本不直接 export 环境变量。这些约定积累起来就是属于你自己的 openrig。