1. 从“openrig”说起一个把 Claude Code 和 Codex 装进统一工作台的想法第一次看到openrig这个词我脑子里蹦出来的不是某个具体软件而是一种“把散落的工具收进一个机架”的直觉。rig 在英文里有“装配、搭建、成套设备”的意思open 则点明了它的开放属性。结合热搜里高频出现的 Claude Code、Codex、Node.js、tmux 这几个词我基本能判断出这是一个围绕命令行 AI 编程助手做统一编排、统一接入、统一管理的开源工具或配置方案。它要解决的问题很具体——当你同时用着 Claude Code 和 Codex 两套 CLI又想让它们共用本地模型、共用终端会话、共用一套配置习惯时手动切来切去实在太累了。我自己在过去大半年里主力工作流就是终端里跑 AI 编程助手。最开始只用一套后来因为不同模型在代码补全、长上下文推理、重构建议上的表现差异明显就变成了两套甚至三套并行。结果就是配置文件散落在不同目录环境变量互相打架tmux 窗口开了一堆切换一次要敲好几条命令。openrig这个标题之所以吸引我是因为它暗示了一种“机架式”的思路——把 Claude Code、Codex 这些工具当成可插拔的模块统一挂载、统一供电、统一散热。这篇文章我就按这个思路把从环境准备到多工具协同的完整链路拆开讲适合已经上手过至少一个 CLI 助手、想进一步做工程化整合的读者。需要先说明的是openrig目前并不是一个我能在官方渠道查到的成熟产品名它更像是一个社区里流传的项目代号或配置集合的统称。所以下文我会基于“一个合格的终端 AI 工作台应该长什么样”这个合理推断来展开所有具体配置都标注清楚是常见实践你可以直接抄也可以按自己环境改。核心目标只有一个让你在同一台机器上把 Claude Code 和 Codex 跑得稳、切得快、管得住。2. 整体设计与思路拆解为什么是 Node.js tmux 这套组合2.1 核心需求拆解多 CLI 助手并行的三个痛点在动手之前先把需求想清楚。我总结下来同时使用 Claude Code 和 Codex 这类工具的人绕不开三个痛点。第一个痛点是运行时依赖冲突。Claude Code 和 Codex 的 CLI 大多基于 Node.js 生态分发通过 npm 全局安装。但不同工具对 Node.js 版本的要求并不总是一致有的要求 LTS有的在新版本上才修掉某个 bug。如果全局只有一个 Node 版本升级一个工具可能弄坏另一个。热搜里那条error installing 24.21.0: node.js v24.21.0 is not yet released就是典型的版本管理翻车现场——你照着某个教程敲了安装命令结果那个版本号根本不存在或者还没正式发布。第二个痛点是会话状态难以保持。CLI 助手跑起来之后往往需要保持一个长驻的交互会话中途你去查个文档、改个文件回来发现会话断了上下文丢了。tmux 在这里的价值就体现出来了它把会话和终端窗口解耦你可以随时 detach过一小时再 attach 回来AI 助手还在原地等你。热搜里claude code如何直接执行终端命令这类问题本质上也是在问“怎么让助手和我的终端环境无缝配合”而 tmux 正是那个粘合层。第三个痛点是模型接入的碎片化。有人用官方订阅有人接第三方 API有人想调本地模型。热搜里claude code 调用lmstudio的本地模型、codex接入deepseek、使用cc switch 接入 deepseek v4, qwen, glm等模型这些词全都指向同一个诉求我希望用同一套界面背后想换哪个模型就换哪个模型。openrig式的思路就是把这些接入方式抽象成配置而不是每次手动改环境变量。2.2 方案选型为什么不是 Docker而是原生 tmux有人会问既然要隔离环境为什么不用 Docker 给每个工具一个容器我试过结论是对于交互式 CLI 助手Docker 的摩擦成本太高。容器里的文件系统和你宿主机的项目目录之间要挂载AI 助手读写代码时路径映射容易出问题而且容器内的终端交互体验尤其是复制粘贴和快捷键总是不如原生顺滑。所以我的选择是Node.js 版本管理用 nvm 或 fnm会话隔离用 tmux工具本身原生安装。这套组合的好处是轻、快、透明。nvm 让你在同一个用户下切换 Node 版本nvm use 20和nvm use 22之间切换只要一秒tmux 让你在一个终端窗口里开多个 pane每个 pane 跑一个助手互不干扰。热搜里node.js是干什么的、node.js安装、node.js lts下载这些基础问题恰恰说明很多人卡在第一步而 nvm 能把这一步的试错成本降到最低。提示如果你在 Windows 上nvm 的原生体验一般建议用 fnm 或者直接在 WSL2 里操作。热搜里claude code windows、codex安装 windows桌面版说明 Windows 用户不少但 CLI 生态在类 Unix 环境下确实更顺。2.3 目录结构设计让配置有地方安放一个清晰的目录结构是后续所有操作不混乱的前提。我习惯这样组织~/ai-rig/ ├── envs/ # 各工具的独立环境配置 │ ├── claude.env │ └── codex.env ├── scripts/ # 启动、切换、健康检查脚本 │ ├── start-claude.sh │ ├── start-codex.sh │ └── switch-model.sh ├── logs/ # 会话日志方便回溯 └── tmux/ # tmux 会话配置 └── ai-workbench.conf这个结构的关键在于环境变量与工具解耦。claude.env里只放 Claude Code 需要的变量codex.env里只放 Codex 需要的。启动脚本负责 source 对应的 env 文件再拉起工具。这样你想换模型只改 env 文件不动启动逻辑。热搜里codex配置、claude code官方文档链接这类需求落到实操上就是“配置放哪、怎么生效”这个结构直接回答了。3. 核心细节解析与实操要点Node.js、tmux 与工具安装3.1 Node.js 版本管理别再用系统自带的那个系统自带的 Node.js 版本往往偏旧而且你用包管理器升级它可能影响系统里其他依赖 Node 的服务。正确做法是用版本管理器。我推荐 fnm因为它启动快、跨平台、配置简单。安装 fnm 之后装两个 LTS 版本备用# 安装 fnm 后安装两个 LTS 版本 fnm install 20 fnm install 22 # 设置默认版本 fnm default 22 fnm use 20为什么要装两个因为 Claude Code 和 Codex 对 Node 版本的兼容窗口不一定重合。我实测下来把 Claude Code 固定在 Node 20Codex 固定在 Node 22两边都稳。热搜里node.js lts下载、安装node.js是最高频的基础问题但很少有人告诉你“装一个不够要装两个”。这就是经验。注意error installing 24.21.0: node.js v24.21.0 is not yet released这个报错通常是因为你抄了一个不存在的版本号。去 Node.js 官网确认当前 LTS 的实际版本号别信教程里的固定数字。3.2 tmux 会话管理让 AI 助手永不掉线tmux 的核心概念是 session、window、pane 三层。我的用法是一个 session 叫ai里面开三个 window分别叫claude、codex、shell。每个 window 里跑对应的工具。这样我tmux attach -t ai之后按Ctrl-b加数字就能在工具间跳。# 创建名为 ai 的会话 tmux new -s ai # 在会话内重命名当前 window # Ctrl-b , 然后输入 claude # 新建 window # Ctrl-b c然后重命名为 codex # 分离会话 # Ctrl-b d # 重新连接 tmux attach -t ai这套操作看起来简单但有一个关键细节tmux 里的环境变量继承。如果你在 tmux 启动之后才 source 了新的 env 文件tmux 里已有的 pane 不会自动更新。所以我的习惯是所有 env 文件在启动 tmux 之前就准备好或者用tmux send-keys在 pane 里手动 source。热搜里claude code如何直接执行终端命令其实也涉及这个——助手要执行命令得先确保它所在的 shell 环境是对的。3.3 Claude Code 与 Codex 的安装与隔离安装本身不复杂关键是隔离。我的做法是不用全局安装而是用npx或者项目级安装配合不同的 Node 版本。# 在 Node 20 环境下安装 Claude Code fnm use 20 npm install -g anthropic-ai/claude-code # 在 Node 22 环境下安装 Codex fnm use 22 npm install -g openai/codex全局安装的问题是两个工具会共享同一个 npm 全局目录切换 Node 版本时全局包不跟着走。更干净的方式是用npm install装到各自的项目目录然后用npx调用。但这样每次启动要进目录麻烦。折中方案是用 fnm 的--use-on-cd功能进不同目录自动切 Node 版本全局包也就跟着切了。提示热搜里codex is ignoring 1 unrecognized configuration setting这个警告通常是配置文件里写了工具不认识的字段。别慌先确认你的工具版本再去官方文档核对字段名。很多教程抄的是旧版本配置字段早就改了。3.4 模型接入的配置抽象这是openrig思路里最有价值的部分。Claude Code 和 Codex 都支持通过环境变量指定 API 端点和密钥。我把这些抽成 env 文件# claude.env export ANTHROPIC_BASE_URLhttps://your-endpoint.example.com export ANTHROPIC_API_KEYsk-xxxx export ANTHROPIC_MODELclaude-sonnet-4-20250514 # codex.env export OPENAI_BASE_URLhttps://your-endpoint.example.com/v1 export OPENAI_API_KEYsk-yyyy export OPENAI_MODELgpt-5-codex想换模型改这两行就行。热搜里codex接入deepseek、claude code 调用lmstudio的本地模型、使用cc switch 接入 deepseek v4, qwen, glm等模型本质上都是改这几个变量。本地模型的话把 BASE_URL 指向http://localhost:1234/v1这类本地服务地址即可。注意本地模型的上下文窗口和工具调用能力可能和官方有差异复杂任务建议先用小项目试。4. 实操过程与核心环节实现从零搭起一个 openrig 工作台4.1 环境准备清单与版本确认动手前先把清单列出来逐项确认。我踩过的坑是以为装好了结果某个工具的依赖没装全跑起来报错排查半天。组件推荐版本确认命令备注fnm最新稳定版fnm --version替代 nvm启动更快Node.js20 LTS 22 LTSfnm list两个版本都要有tmux3.2 以上tmux -V老版本可能不支持某些配置Claude Code最新版claude --version装在 Node 20 下Codex最新版codex --version装在 Node 22 下确认完版本再检查 shell 配置。fnm 需要在.bashrc或.zshrc里加初始化脚本否则新开的终端不认。tmux 的配置文件放在~/.tmux.conf我建议至少加这几行# ~/.tmux.conf set -g mouse on set -g history-limit 50000 set -g base-index 1 setw -g pane-base-index 1mouse on让你能用鼠标选 pane、调大小对新手友好。history-limit调大方便回溯 AI 助手的输出。base-index从 1 开始符合直觉。4.2 启动脚本的编写与参数计算启动脚本的核心是切 Node 版本、source env、拉起工具、记录日志。以 Claude Code 为例#!/usr/bin/env bash # scripts/start-claude.sh set -euo pipefail # 切到 Node 20 eval $(fnm env --use-on-cd) fnm use 20 # 加载环境变量 source ~/ai-rig/envs/claude.env # 记录启动时间 echo [$(date %Y-%m-%d %H:%M:%S)] starting claude ~/ai-rig/logs/claude.log # 拉起工具日志同时输出到文件 claude 21 | tee -a ~/ai-rig/logs/claude.log这里有个细节set -euo pipefail让脚本遇到错误就退出避免半死不活的状态。tee -a让输出既显示在终端又写进日志。日志文件按工具分开排查问题时不会混。Codex 的脚本类似只是切 Node 22、sourcecodex.env。两个脚本都放在scripts/下加执行权限chmod x ~/ai-rig/scripts/*.sh4.3 tmux 工作台的一键拉起手动开 tmux、开 window、跑脚本还是麻烦。写一个总启动脚本一键搞定#!/usr/bin/env bash # scripts/start-workbench.sh set -euo pipefail SESSIONai # 如果会话已存在直接 attach if tmux has-session -t $SESSION 2/dev/null; then tmux attach -t $SESSION exit 0 fi # 创建会话第一个 window 跑 claude tmux new-session -d -s $SESSION -n claude tmux send-keys -t $SESSION:claude ~/ai-rig/scripts/start-claude.sh C-m # 第二个 window 跑 codex tmux new-window -t $SESSION -n codex tmux send-keys -t $SESSION:codex ~/ai-rig/scripts/start-codex.sh C-m # 第三个 window 留作普通 shell tmux new-window -t $SESSION -n shell # attach 到会话 tmux attach -t $SESSION这个脚本的逻辑是先检查会话是否存在存在就直接进不存在就建。建的时候用-d让会话在后台创建然后用send-keys把启动命令“敲”进对应的 window。这样你 attach 进去的时候两个助手已经在跑了。热搜里claude code使用、codex使用教程讲的多是单工具怎么用而这里解决的是“两个一起用怎么不打架”。4.4 模型切换的实操记录假设我原本用官方模型现在想切到本地模型做实验。操作步骤编辑~/ai-rig/envs/claude.env把ANTHROPIC_BASE_URL改成http://localhost:1234/v1ANTHROPIC_API_KEY随便填一个非空值本地服务通常不校验。在 tmux 的 claude window 里按Ctrl-c退出当前会话。重新运行~/ai-rig/scripts/start-claude.sh。用一句简单的话测试比如“列出当前目录的文件”。实测下来本地模型在简单任务上响应很快但涉及多文件重构时工具调用能力可能不如官方模型。我的经验是本地模型适合做代码解释、单文件修改、写测试复杂重构还是用官方或大参数模型。热搜里claude code 调用lmstudio的本地模型热度高说明很多人想省成本但省成本的前提是任务匹配。注意切换模型后如果工具报cc switch local proxy failed while handling codex endpoint /responses这类错误先检查 BASE_URL 的路径对不对。很多本地服务的 OpenAI 兼容端点是/v1而工具可能默认拼了/responses路径对不上就 404。5. 常见问题与排查技巧实录5.1 安装阶段的典型报错与解决安装阶段的问题八成出在 Node 版本和网络。我整理了一张速查表报错信息可能原因解决思路node.js v24.21.0 is not yet released版本号不存在去官网查实际 LTS 版本npm ERR! code EACCES全局目录权限不足用 fnm 管理别用 sudo npmcommand not found: claude全局 bin 不在 PATH检查 fnm 的 shell 初始化codex is ignoring 1 unrecognized configuration setting配置字段过时核对官方文档字段名your organization has disabled claude subscription access账号权限问题确认订阅状态或换接入方式EACCES这个坑我踩过。早期用系统 Nodenpm install -g要 sudo装完的文件属主是 root后面升级又出问题。换成 fnm 之后全局包装在用户目录下再没遇到过权限问题。热搜里安装node.js、node.js下载是入门问题但入门问题往往最影响后续体验。5.2 运行阶段的会话与网络问题运行阶段最常见的是会话断连和网络超时。会话断连用 tmux 解决前面讲过了。网络超时则要看具体接入方式。如果是第三方 API先确认端点可达curl -sS -o /dev/null -w %{http_code}\n https://your-endpoint.example.com/v1/models返回 200 说明通返回 401 说明密钥有问题返回 404 说明路径不对。这个命令比在工具里瞎试快得多。另一个高频问题是codex无法加载组织设置。这通常和账号的团队配置有关个人账号一般不会遇到。如果你用的是团队账号联系管理员确认权限。热搜里codex登录、codex安装热度高说明很多人在登录环节卡住我的建议是先用最简单的官方接入跑通再折腾第三方和本地模型别一上来就搞复杂配置。5.3 多工具协同的避坑经验同时跑 Claude Code 和 Codex有几个坑我踩过分享出来。第一个坑是端口冲突。如果你给两个工具都配了本地代理注意它们监听的端口别撞。我习惯给 Claude Code 用 8080Codex 用 8081。第二个坑是日志混淆。两个工具的日志如果写同一个文件排查时根本分不清谁是谁。所以前面强调日志按工具分开。第三个坑是快捷键冲突。tmux 的前缀键默认是Ctrl-b而某些终端或编辑器也用这个组合。如果冲突改 tmux 前缀键# ~/.tmux.conf set -g prefix C-a bind C-a send-prefix改成Ctrl-a之后和大多数工具的冲突就少了。第四个坑是上下文串味。你在 Claude Code 里讨论的方案切到 Codex 时它不知道。我的做法是重要上下文写进项目里的一个CONTEXT.md两个工具都让它先读这个文件。这样切换工具时上下文能接上。5.4 性能与资源占用的观察两个 CLI 助手同时跑内存占用不容忽视。我实测下来每个助手进程大概占 200MB 到 500MB 内存取决于上下文长度。如果你机器内存紧张建议一次只跑一个另一个用 tmux 挂着但不活跃。CPU 占用主要在模型推理时本地模型尤其明显。如果你用本地模型跑大任务时机器会卡这是正常的。我的经验是本地模型跑在独立窗口别和你的编辑器抢资源官方 API 则几乎不占本地 CPU。提示热搜里node.js是干什么的这类基础问题其实反映了一个现实——很多人是被“必须装 Node”这件事挡在门外的。但只要你用 fnm 把 Node 管起来后面所有工具的安装都是npm install一句话的事门槛比想象中低。6. 工具选型与扩展openrig 思路还能怎么用6.1 除了 Claude Code 和 Codex还能挂什么openrig的“机架”思路是通用的。任何基于命令行的 AI 工具都可以用同样的方式挂进来。比如代码审查工具、文档生成工具、甚至自定义的脚本。关键是统一 env 管理、统一 tmux 会话、统一日志。我现在的ai会话里有四个 windowclaude、codex、shell、logs。logs window 里跑tail -f看两个工具的日志排查问题时不用切来切去。6.2 配置的版本化管理~/ai-rig/这个目录我建议用 git 管起来。env 文件里的密钥不要提交用.gitignore排除然后提供一个envs/*.env.example模板。这样换机器时clone 下来、填密钥、跑启动脚本十分钟就能恢复工作环境。# .gitignore envs/*.env logs/这个习惯看起来小但换电脑或重装系统时价值巨大。热搜里claude code安装、codex安装教程反复出现说明很多人每次都在重新配环境。版本化管理能让你一次配好到处复用。6.3 从单机到多机的延伸如果你有多台机器比如一台台式机跑本地模型一台笔记本做日常开发openrig的思路也能延伸。把 env 文件和脚本放在同步目录里两台机器用同一套配置。本地模型那台把 BASE_URL 指向局域网地址笔记本就能远程调用。这样笔记本不用扛大模型也能享受本地推理的低延迟。这个延伸的关键是网络可达性和密钥管理。局域网内调用注意防火墙放行对应端口密钥别硬编码在脚本里用环境变量或密钥管理工具。7. 我个人的实操体会这套工作台我用了几个月最大的感受是工具的价值不在于多而在于切换成本低。以前我因为切换麻烦常常一个工具用到黑哪怕它不适合当前任务。现在 tmux 里Ctrl-b加数字就能切env 文件改一行就能换模型我变得更愿意根据任务选工具了。写测试用响应快的做重构用上下文长的查文档用能联网的。另一个体会是日志比想象中重要。AI 助手的输出有时候很长当时没细看事后想回溯没有日志就抓瞎。现在两个工具的日志都留着偶尔翻一翻能发现不少当时忽略的细节。最后分享一个小技巧给 tmux 的每个 window 设一个明显的名字并且在.tmux.conf里打开pane-border-status这样你一眼就知道当前在哪个工具里不会敲错命令。# ~/.tmux.conf set -g pane-border-status top set -g pane-border-format #{pane_title}这个配置加上之后每个 pane 顶部会显示标题多窗口操作时不容易迷路。