1. 为什么要在 Linux 上折腾这两个命令行工具先说清楚这两个东西是什么。Codex CLI 和 Claude Code本质上都是把大模型能力塞进终端里的命令行工具。前者偏向代码生成与补全后者偏向对话式编程辅助能读文件、改代码、跑命令。它们解决的核心问题是不用离开终端不用切浏览器不用复制粘贴直接在 shell 里跟模型对话完成编码任务。适合谁看如果你日常在 Linux 环境下写代码习惯用 vim、tmux、ssh 远程开发那这两个工具能省掉大量窗口切换的时间。如果你只是偶尔写几行脚本那可能用网页版更省事。这篇文章面向的是前者——那些把终端当主战场的人。我自己的场景是这样的一台远程开发机Ubuntu 22.04没有图形界面所有操作通过 ssh 完成。之前用网页版模型辅助编码每次都要把代码复制出来、粘贴进去、再把结果复制回来效率极低。后来把这两个 CLI 工具装上直接在项目目录里让模型读文件、改代码整个流程顺畅了很多。安装过程本身不复杂但坑不少。Node 版本不对、npm 全局路径没配好、权限问题、网络超时每一个都能卡住新手。下面我把整个流程拆开讲包括每一步为什么这么做、遇到问题怎么排查。2. 安装前的环境准备与依赖梳理2.1 系统要求与基础工具检查这两个工具都是基于 Node.js 生态的所以第一步是确认系统里有没有 Node 和 npm。打开终端跑node -v npm -v如果输出了版本号说明已经装了。如果没有或者版本太老就需要先装 Node。Codex CLI 和 Claude Code 一般要求 Node 18 以上推荐 20 LTS 版本。低于 18 会在安装时报错提示引擎不兼容。除了 Node还需要确认几个基础工具curl或wget用于下载安装脚本或二进制文件git部分安装方式依赖 git 拉取仓库build-essentialUbuntu/Debian或Development ToolsCentOS/RHEL某些 npm 包需要编译原生模块检查命令which curl git gcc make如果某个命令没有输出路径说明没装。Ubuntu 下可以一次性补齐sudo apt update sudo apt install -y curl git build-essential注意不要跳过 build-essential。我遇到过好几次 npm 安装时报node-gyp错误最后都是因为缺少编译工具链。提前装好省得后面折腾。2.2 Node 版本管理为什么推荐用 nvm 而不是系统包管理器直接用apt install nodejs装出来的 Node 版本往往偏旧Ubuntu 22.04 默认源里是 12.x根本跑不了这两个工具。有人会用 NodeSource 的源装新版本但这样装出来的 Node 是系统级的切换版本很麻烦。我更推荐用 nvmNode Version Manager。原因很简单nvm 把 Node 装在用户目录下不需要 sudo切换版本一条命令搞定卸载也干净。具体操作curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash装完之后重新加载 shell 配置source ~/.bashrc然后安装 Node 20nvm install 20 nvm use 20 nvm alias default 20最后一行是把 20 设为默认版本这样每次新开终端都自动用这个版本。验证一下node -v # 应该输出 v20.x.x npm -v # 应该输出 10.x.x实操心得如果你之前用 apt 装过 Node先卸载干净再装 nvm否则可能出现路径冲突。卸载命令sudo apt remove --purge nodejs npm然后手动删掉/usr/lib/node_modules和/usr/local/lib/node_modules残留目录。2.3 npm 全局路径配置避免权限报错的根本方法npm 默认的全局安装路径是/usr/local/lib/node_modules普通用户没有写权限。直接npm install -g会报EACCES错误。很多人图省事用sudo npm install -g但这会带来两个问题一是装出来的包属主是 root后续更新可能出问题二是某些包的 postinstall 脚本以 root 运行有安全风险。正确做法是把 npm 全局路径改到用户目录下mkdir -p ~/.npm-global npm config set prefix ~/.npm-global然后把路径加到 shell 配置里echo export PATH~/.npm-global/bin:$PATH ~/.bashrc source ~/.bashrc验证配置是否生效npm config get prefix # 应该输出 /home/你的用户名/.npm-global这样以后npm install -g装的包都在用户目录下不需要 sudo也不会有权限问题。常见坑如果你用的是 zsh 而不是 bash要把路径加到~/.zshrc而不是~/.bashrc。我见过有人改了 bashrc 但用的是 zsh折腾半天找不到命令。3. Codex CLI 安装实操与配置细节3.1 安装方式选择npm 全局安装 vs 二进制下载Codex CLI 提供两种安装方式npm 全局安装和直接下载二进制。我推荐 npm 方式原因是更新方便一条npm update -g就能升级而且依赖管理交给 npm 处理不用手动管版本。安装命令npm install -g openai/codex如果你用的是其他发行版或者 npm 源速度慢可以临时切换源npm install -g openai/codex --registryhttps://registry.npmmirror.com装完之后验证codex --version如果提示command not found大概率是 PATH 没配好。检查~/.npm-global/bin是否在 PATH 里echo $PATH | tr : \n | grep npm-global没有输出的话回到 2.3 节重新配置。3.2 首次运行与认证配置第一次运行codex会提示你登录或配置 API Key。具体流程codex它会引导你完成认证。如果你有 API Key可以直接设置环境变量export OPENAI_API_KEY你的key为了持久化把这行加到~/.bashrc里。但我不建议直接把 key 写在 bashrc 里因为任何能读这个文件的人都能拿到 key。更安全的做法是写到一个单独的文件然后 sourceecho export OPENAI_API_KEY你的key ~/.codex_env chmod 600 ~/.codex_env echo source ~/.codex_env ~/.bashrcchmod 600确保只有你自己能读这个文件。注意事项不要把 API Key 提交到 git 仓库。如果你在项目目录里建了.env文件存 key记得把.env加到.gitignore里。我见过有人不小心把 key 推到公开仓库几分钟内就被刷了几百美元的额度。3.3 配置文件详解与常用参数调优Codex CLI 的配置文件默认在~/.codex/config.yaml。常用配置项model: gpt-4 temperature: 0.7 max_tokens: 4096model指定使用的模型。不同模型能力和价格差异很大日常补全用轻量模型就够复杂重构再切到强模型。temperature控制输出随机性。写代码建议 0.2 到 0.5太高会生成奇怪的代码太低会过于死板。max_tokens单次响应的最大 token 数。设太小会导致回答被截断设太大浪费额度。我自己的配置是 temperature 0.3max_tokens 8192。这个组合在代码生成任务上表现比较稳既不会太发散也不会因为截断导致代码不完整。3.4 验证安装跑一个最小可用示例装完之后别急着上项目先跑个简单测试确认工具能正常工作。新建一个测试目录mkdir ~/codex-test cd ~/codex-test然后运行codex 写一个 Python 函数计算斐波那契数列的第 n 项如果一切正常终端会输出生成的代码。如果报错根据错误信息排查错误信息原因解决方法command not foundPATH 未配置检查~/.npm-global/bin是否在 PATH401 UnauthorizedAPI Key 无效重新检查 key 是否正确429 Too Many Requests额度用完或频率限制检查账户余额降低调用频率ECONNREFUSED网络问题检查网络连接确认能访问 API 端点Cannot find module安装不完整卸载重装npm uninstall -g openai/codex npm install -g openai/codex4. Claude Code 安装与双工具协同配置4.1 Claude Code 安装步骤与差异点Claude Code 的安装方式和 Codex CLI 类似也是 npm 全局安装npm install -g anthropic-ai/claude-code验证claude --versionClaude Code 和 Codex CLI 的一个显著差异是Claude Code 更强调项目上下文感知。它启动时会扫描当前目录的文件结构构建一个项目索引这样你在对话中引用文件时它能直接读取内容。Codex CLI 在这方面相对轻量更多是单次问答模式。认证配置export ANTHROPIC_API_KEY你的key同样建议写到单独文件里不要直接暴露在 bashrc。4.2 两个工具能否共存路径、配置、认证的隔离完全可以共存因为它们装在不同的 npm 包目录下命令名也不冲突codex和claude。配置目录也是分开的Codex 用~/.codex/Claude Code 用~/.claude/。API Key 环境变量名不同不会互相覆盖。唯一需要注意的是 npm 全局路径。两个工具都装在~/.npm-global/bin下只要这个路径在 PATH 里两个命令都能找到。验证共存which codex which claude两条命令都应该输出~/.npm-global/bin/下的路径。4.3 项目级配置让工具理解你的代码库Claude Code 支持项目级配置文件。在项目根目录建一个.claude/config.yamlproject_name: my-project language: python ignore_patterns: - *.log - node_modules/ - __pycache__/ignore_patterns告诉工具哪些文件不用扫描。这个配置很实用因为大项目里 node_modules 动辄几万个文件全扫一遍既慢又浪费 token。Codex CLI 也支持类似的项目级配置放在.codex/config.yaml。我一般会把两个配置文件都加上内容基本一致。实操心得把.claude/和.codex/加到.gitignore里。这些配置里可能包含本地路径、API 端点等信息不适合提交到仓库。但如果你想让团队共享配置可以建一个.claude/config.example.yaml作为模板提交实际配置文件忽略。4.4 终端集成alias 与快捷命令设置每天敲codex和claude太累可以设 alias。加到~/.bashrcalias cxcodex alias ccclaude alias cxrcodex --review alias ccfclaude --file这样cx就是 codexcc就是 claude。cxr是代码审查模式ccf是带文件参数的模式。还可以设一个组合命令把当前 git diff 喂给工具做审查alias reviewgit diff | codex 审查以下代码变更指出潜在问题这个 alias 我几乎每天都在用提交前跑一遍能抓到不少低级错误。5. 常见报错与排查技巧实录5.1 安装阶段高频问题速查问题现象根本原因解决步骤EACCES: permission deniednpm 全局路径权限不足按 2.3 节配置用户级 prefixnode-gyp编译失败缺少 build-essentialsudo apt install build-essentialnpm ERR! network timeout源速度慢切换镜像源或重试Unsupported engineNode 版本过低用 nvm 装 Node 20command not foundPATH 未包含 npm 全局 bin检查并重新 source bashrc安装卡住不动网络问题或包体积大加--verbose看详细日志5.2 运行阶段认证与网络问题认证问题最常见的是 API Key 格式错误。有些 Key 包含特殊字符直接写在 bashrc 里可能被 shell 解释。用单引号包起来export OPENAI_API_KEYsk-...网络问题方面如果终端提示连接超时先确认基础网络是否正常curl -I https://api.openai.com如果 curl 也超时说明是网络层面的问题需要检查 DNS 或代理设置。如果 curl 正常但工具报错可能是工具内部的超时设置太短可以在配置文件里调大 timeout 值。5.3 工具升级与版本回退npm 装的包升级很简单npm update -g openai/codex npm update -g anthropic-ai/claude-code但有时候新版本会引入 bug需要回退到旧版本npm install -g openai/codex1.2.3指定版本号即可。查看可用版本npm view openai/codex versions避坑技巧升级前先记下当前版本号。我遇到过升级后配置格式变了旧配置文件不兼容折腾半天才找到问题。现在每次升级前都跑codex --version记一下出问题能快速回退。5.4 性能优化减少延迟与 token 消耗两个工具用久了会发现大项目里响应越来越慢。主要原因是每次请求都携带了大量上下文。优化方法配置ignore_patterns排除无关目录不要在整个项目根目录启动进入具体子模块再启动用--file参数只传相关文件而不是让工具自己扫定期清理对话历史避免上下文无限增长我实测下来一个中型 Python 项目配置好 ignore 之后首次响应时间从 8 秒降到 2 秒左右token 消耗减少约 60%。6. 把两个工具用顺手的几个实战建议装好只是第一步真正提升效率的是使用习惯。我总结了几个自己踩坑后形成的做法。第一不要指望工具一次生成完美代码。把它当成一个反应很快但需要review的初级工程师。生成的代码一定要自己过一遍尤其是边界条件和错误处理模型经常忽略这些。第二善用管道。Linux 的优势就是管道可以把 git diff、日志、测试输出直接喂给工具pytest 21 | codex 分析测试失败原因这比手动复制错误信息高效得多。第三给工具足够的上下文。Claude Code 会自己扫项目但 Codex CLI 不会。用 Codex 时如果问题涉及多个文件手动把相关文件内容贴进去或者用--file参数指定。上下文越完整回答质量越高。第四定期检查 API 用量。两个工具都按 token 计费大项目里一天跑下来可能消耗不少。设个预算提醒避免月底账单吓一跳。第五保持工具更新但不要追最新版。等新版本发布一周后再升级让其他人先踩坑。生产环境尤其如此。最后分享一个我常用的组合技用 Claude Code 做代码审查用 Codex CLI 做代码生成。审查时 Claude 的项目上下文感知更强能发现跨文件的问题生成时 Codex 响应更快适合快速迭代。两个工具各有所长配合使用比单用一个效率高不少。