先交代一下背景我平时主力机是 Windows但很多 AI 编程工具在 Linux 环境里跑得更顺所以 WSL 是我的日常开发环境。最近想把 Claude Code 用起来却懒得一步步敲安装命令正好手头有 OpenAI 的 Codex CLI就干脆让 Codex 在 WSL 里帮我把 Claude Code 装好、配好。整个过程像在远程指挥一个懂 Linux 的实习生它自己会开终端、敲命令、读报错、改配置我在旁边盯着。这篇文章就是这次“AI 代操作”的完整记录包括中间遇到的报错、我介入干预的节点以及最后两个工具在日常开发里怎么分工。如果你也想在 Windows 上用 WSL 跑 AI 编程工具或者好奇 Codex 这类自主代理到底能独立干多少活这篇应该能给你一些真实参考。1. 先说清楚WSL、Claude Code、Codex 分别是什么为什么组合在一起1.1 WSL 让我在 Windows 里用 Linux而 Claude Code 正好需要它WSL 的全称是 Windows Subsystem for Linux它允许你在 Windows 里直接跑一个真实的 Linux 发行版而不需要装虚拟机。对开发者来说最实用的点在于文件访问很快、终端体验很原生、而且能直接调用 Windows 文件系统里的代码目录。你可以在 Windows 的 VSCode 里打开 WSL 目录所有命令行工具都跑在 Linux 环境中日常开发不会感到两边是割裂的。Claude Code 是 Anthropic 推出的终端编程工具它本质上是一个运行在命令行里的 AI 编程代理。你说需求它帮你改文件、跑命令、查文档甚至维护整个项目。它需要 Node.js 环境在 Linux 下表现很稳定。虽然它也有 Windows 版本的支持但在实际体验中WSL 里的 Linux 环境对这类 CLI 工具更友好。比如路径处理、shell 脚本执行、权限管理这些在原生 Windows 终端里容易出现各种水土不服在 WSL 里却很少出问题。很多第一次接触 WSL 的人会问一个问题为什么不用双系统或者虚拟机双系统太重来回重启虚拟机资源开销太大文件共享也麻烦。WSL2 是跑在轻量级虚拟机上的但它的启动和关闭是无感的而且默认和 Windows 网络、文件系统做了深度集成。用习惯了之后你会感觉 WSL 就像 Windows 内置了一个 Linux 终端窗口。1.2 Codex 在这件事里扮演什么角色Codex 是 OpenAI 出的一个开源命令行智能体我们可以把它理解为“一个能自己操作终端的 AI 助手”。和普通的聊天式 AI 不同Codex 能真正执行任务它会规划步骤、在终端里敲命令、读取输出结果、根据报错修改思路然后继续执行。整个过程像是有一个懂技术的远程实习生坐在电脑前你把目标告诉它它自己去找方法。在这次任务里我给 Codex 的目标是在 WSL 的 Ubuntu 环境里安装 Claude Code并完成基础配置。听起来是一件很机械的事情但如果每一步都自己手动敲至少要经历 Node.js 版本检查、npm 源配置、权限处理、环境变量写入等多个环节。Codex 的意义在于它能把“实现目标”这件事接管过去而不是简单地给我一段安装教程。需要说明的是Codex 和 Claude Code 虽然都是 AI 编程工具但定位不同。Claude Code 更像一个结对编程搭档你主导方向和决策它帮你执行具体的代码修改。Codex 则偏向“任务代理”你给它一个目标它自己拆解、执行、修正甚至可以连续操作多步而无需你干预。这次我用 Codex 去装 Claude Code本质上就是在测试这种“AI 代理执行真实任务”的能力边界。1.3 为什么值得让 AI 去装 AI听起来有点套娃但这件事其实是有效的检测方式。第一次装 Claude Code 的人通常会卡在几个地方版本不兼容、环境变量配置错误、权限不够、网络下载超时。这些坑用文字写出来很容易但实际操作时依然要花时间排查。让 Codex 来做虽然不一定比人快但它会把整个操作过程记录下来你全程能看到相当于一边看实习生动手一边自己学了一遍。另外这次操作还能验证 Codex 的自主性到底到什么程度。它能自己发现报错并调整方案吗它需要我介入多少次它在什么情况下会卡住这些问题光看宣传是得不出来的只有实际踢一脚才知道。从结果来看Codex 确实完成了大部分工作但也暴露了一些值得注意的短板后面我会详细讲。2. 准备阶段把 WSL 环境收拾到能干活2.1 WSL 安装与版本检查一次搞明白 needs updatingWindows 上安装 WSL 现在非常简单打开管理员权限的 PowerShell 或终端运行wsl --install它会自动装好 WSL2 和默认的 Ubuntu 发行版。装完重启然后设置 Linux 用户名和密码就基本能用了。但很多人的系统是几年没更新过的 Windows或者被组策略限制住了这时运行wsl --install可能没有任何反应或者提示版本过旧。我就遇到过终端直接提示WSL needs updating. Your version of Windows Subsystem for Linux is too old.意思是当前系统的 WSL 版本太老。处理办法是运行wsl --update把 WSL 内核更新到最新版本。如果你连 WSL 都没有先执行wsl --install --no-distribution再单独安装发行版。还有一个容易被忽略的点确保你的 Windows 版本和 CPU 虚拟化功能都正常否则 WSL2 起不来。如果你想把 Ubuntu 安装到 D 盘而不是默认占满 C 盘空间可以用下面的方式先用wsl --install装好默认发行版然后wsl --export Ubuntu D:\ubuntu-backup.tar再wsl --unregister Ubuntu最后wsl --import Ubuntu D:\wsl\Ubuntu D:\ubuntu-backup.tar --version 2。这套操作的本质是把发行版整体打包、注销、再导入到新位置。好处是 C 盘空间压力小很多尤其对 SSD 容量紧张的人很实用。注意导入后默认登录用户会变成 root需要自己改回原来的用户这一步不复杂但容易忽略。检查当前 WSL 版本用wsl --version输出里能看到 WSL 版本号和内核版本号。如果你的版本低于 2.0.0建议更新因为新版在内核、网络和文件性能上都改进了很多。我在操作前刻意把 WSL 更新到了最新版本为的就是减少后面代操作过程中的环境干扰。2.2 Node.js 装好之后npm 很慢才是大问题Claude Code 和 Codex 都是基于 Node.js 的所以第一步必须在 WSL 里装好 Node.js。我的建议是不要直接apt install nodejs因为仓库里的版本普遍偏旧CLI 工具经常要求 Node 18 以上。用 nvm 来管理版本更灵活以后想切换也方便。curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash装完后重新加载 shell然后安装 Node 的 LTS 版本nvm install --lts node -v npm -v这一步比较顺利真正让我头疼的是后面的 npm 安装速度。默认的 npm 官方源在国内下载速度实在惨不忍睹经常一个包下载到一半直接超时。这时候需要换源我用的是 npmmirror这属于常规的镜像加速操作国内开发者都在用。npm config set registry https://registry.npmmirror.com换源之后下载速度差别很大之前可能要等几分钟的安装现在十几秒就搞定。如果你不想全局修改 npm 源也可以只在安装时临时指定npm install --registryhttps://registry.npmmirror.com还有一个容易踩的坑WSL 默认的 DNS 解析偶尔会抽风导致从 GitHub 下载时连接超时。如果你发现各个源都正常但就是下载不了一点东西可以检查/etc/resolv.conf或者干脆重启一下 WSL。有个非常实用的命令可以解决大部分玄学网络问题wsl --shutdown然后重新打开 WSL 窗口系统会重新初始化网络栈。这个方法简单粗暴但实测下来对很多“突然什么都下载不了”的情况都很管用。Node 环境就绪后我顺手把npm也升级到了最新版本。这一步其实是为了防止后面 CLI 安装时遇到权限问题。npm 默认安装全局包的目录需要权限如果你不是 root 用户经常会碰到 EACCES 报错。提前改一下 npm 的全局安装目录或者直接确保用户对目录有写权限能省不少麻烦。3. 安装 Codex 并让它开始代操作3.1 安装 Codex CLI一条 npm 命令的事Codex CLI 的安装方式主要取决于你的系统。在 WSL 的 Ubuntu 里最直接的方式是通过 npm 全局安装npm install -g openai/codex安装完成后验证一下codex --version如果能看到版本号说明安装成功。这里要注意一点Codex 的官方 npm 包名可能随着版本迭代有变化如果你遇到npm ERR! 404或者找不到包去 OpenAI 官方文档确认最新的包名。另外有些人还会遇到全局安装目录不在 PATH 里的问题导致codex命令无法识别。这时候检查一下npm config get prefix看全局 bin 目录有没有被加入 PATH。还有一种安装方式是使用官方提供的安装脚本可以自动处理依赖和 PATH 配置。但对于 WSL 环境来说我反而推荐 npm 方式因为后续升级用一条命令就能搞定而且和 Node 环境绑定避免脚本安装时出现版本冲突。3.2 登录与鉴权选 OAuth 还是 API KeyCodex 安装完成后第一次使用需要登录。运行codex login它会在终端里生成一个链接让你在浏览器里完成授权。浏览器弹出授权页面后登录 OpenAI 账号允许 Codex 访问你的账号权限然后回到终端就能看到登录成功的提示。这种方式适合个人日常使用因为它不涉及明文保存密钥登录状态由系统管理。但我个人更喜欢另一种方式设置OPENAI_API_KEY环境变量。原因很简单在 WSL 里我经常切换不同的开发环境API Key 方式可以让配置显式化也方便在不同机器间迁移。export OPENAI_API_KEY你的密钥不过要注意直接把 API Key 写进终端会话只对当前会话有效。为了持久化需要追加到~/.bashrc或~/.zshrc里。我当时的做法是echo export OPENAI_API_KEY你的密钥 ~/.bashrc source ~/.bashrc如果你担心 Key 以明文形式写在配置里也可以使用系统级的密钥管理器。但在 WSL 这种个人开发环境里~/.bashrc方案已经能满足绝大多数场景需求。3.3 第一次下达任务登录完成后我给 Codex 下达了第一个任务指令codex 在当前的 WSL Ubuntu 环境里安装 Claude Code并完成基础配置包括安装 Node.js 依赖、配置 API Key、验证 claude 命令可用Codex 接到任务后第一反应不是立即执行而是先在终端里给出了一个简短的计划检查当前环境中的 Node.js 和 npm 版本检查是否已经安装 Claude Code安装 Claude Code配置环境变量验证安装看到这个计划我心里比较满意至少说明它能把任务分解为可执行步骤。接下来它就开始了先执行node -v和npm -v确认环境然后检查claude命令是否存在发现未安装后开始安装步骤。整个过程中我一直在旁边观察Codex 每执行一个命令都会先输出命令行内容然后等待命令执行完毕再读取输出结果。这个“计划-执行-观察-反馈”的循环正是 AI 代理和普通脚本的最大区别。4. 现场记录Codex 从安装到配置 Claude Code 的全过程4.1 执行安装命令时它在想什么Codex 执行安装命令时并没有直接一股脑地运行npm install而是先做了一次环境确认。它检查了 Node 版本确认满足要求然后才运行npm install -g anthropic-ai/claude-code这一步值得展开说说。Claude Code 的 npm 包名是anthropic-ai/claude-code和 Codex 一样也需要全局安装。安装过程中npm 会下载依赖包并创建全局命令链接。如果安装过程中遇到权限问题Codex 会识别到 EACCES 错误然后尝试用sudo重新执行命令。如果你用的用户不是 rootsudo 密码会是一个交互点Codex 无法自己输密码这时候它会停下来等我输入。我在实际操作中遇到的第一个卡点就在这里。Codex 执行命令时发现 npm 全局目录权限不足于是尝试sudo npm install -g anthropic-ai/claude-code但它并不知道我的 sudo 密码。于是它停下来在终端里提示我输入密码。我输入密码后它继续执行剩余步骤。这里给大家一个经验如果你经常要在 WSL 里折腾 npm 全局包干脆提前把全局目录放到用户可写的位置省去后面所有 sudo 交互。mkdir -p ~/.npm-global npm config set prefix ~/.npm-global echo export PATH~/.npm-global/bin:$PATH ~/.bashrc source ~/.bashrc设置完之后全局安装包会直接安装到用户目录下不用每次都用 sudo。Codex 在执行任务时也能减少一次需要我介入的交互。这是我踩过一次之后学到的——把环境本身收拾利索AI 代操作的流畅度会大幅提升。4.2 配置 API Key 与 shell 环境安装完成后Codex 开始配置 Claude Code。和 Codex 一样Claude Code 也支持多种鉴权方式。Codex 先查看了当前是否已有ANTHROPIC_API_KEY环境变量发现没有于是尝试直接运行claude命令查看它的交互式引导流程。claude首次运行时会启动一个交互式界面询问你是要登录 Claude 账号还是使用 API Key。Codex 在这里卡住了。因为它无法在非交互式模式下替我做这个选择交互式界面会等待用户输入而 Codex 此时没有权限去操作这个终端输入。我介入了第一次决策告诉 Codex使用 ANTHROPIC_API_KEY 环境变量方式配置不需要走交互式登录。Codex 收到指令后开始在~/.bashrc里追加环境变量配置。它执行了类似这样的操作echo export ANTHROPIC_API_KEY你的密钥 ~/.bashrc然后执行source ~/.bashrc使配置生效。这里要提醒一句如果 API Key 内容是包含特殊字符的直接在echo命令里拼接可能会导致转义问题。Codex 在写配置时我专门留意了一下它是否用了引号包裹确认无误后才让它继续。配置完成后Codex 运行了claude --version输出0.x.x版本号。这表明 Claude Code 已经安装成功并且环境变量也已经生效。接着 Codex 又尝试运行了claude命令不过这次它没有让我进入交互界面而是直接退出因为在非交互式终端环境里CLI 工具无法正常启动。我后来自己手动打开一个终端运行claude命令才正式进入对话界面。4.3 我介入的两次关键节点整个代操作过程中我一共主动介入了两次。第一次是上文提到的 API Key 方式选择第二次是整理配置文件。Codex 在配置~/.bashrc时因为前面已经追加过OPENAI_API_KEY现在又追加ANTHROPIC_API_KEY它可能因为剪切复制逻辑的问题把部分内容重复写入了。我在终端里看到~/.bashrc中有两行几乎相同的内容虽然不影响最终使用但看着难受。我让 Codex 检查并清理~/.bashrc中的重复行只保留一份配置。Codex 很听话地执行了清理同时用grep检查了环境变量是否重复定义。清理完成后它再次运行source ~/.bashrc然后验证了claude --version确保清理没有破坏环境。这两个介入点让我意识到一个事实AI 代操作目前还不能做到完全无人值守。它擅长的是在一个明确的任务空间内反复尝试但一旦遇到“需要用户偏好决策”的情况它必须停下来等你。而且它的操作是有累积状态的如果中间有一行命令写错了它会基于错误的输出继续推导这时候人的监督和及时纠偏就非常重要。5. 踩坑实录三个报错的排查思路5.1 那个吓人的报错cc switch local proxy failed while handling codex endpoint /responses这是我这次操作中最诡异的一条报错。当时我正在测试 Codex 的一个新功能突然终端里弹出cc switch local proxy failed while handling codex endpoint /responses初次看到这个报错的反应肯定是我哪里网络没配好。但排查了一圈之后发现这个错误并不一定和“代理”两个字表面上看起来的意思直接相关。我在 Codex 的 GitHub 仓库 issue 区翻了半天发现类似报错的场景多数发生在Codex 版本太旧、本地缓存里存了旧的服务配置或者多个 CLI 工具版本共存导致内部服务路由冲突。我的排查路径是这样的。先检查 Codex 的当前版本codex --version发现版本有点旧于是执行了升级npm update -g openai/codex升级之后先清掉 Codex 可能存下来的本地缓存和会话数据codex logout rm -rf ~/.codex codex login这里的关键是把本地的会话数据和内部配置文件重置让新版本重新生成。重新登录后那个报错就再也没出现过。额外提醒一下如果你也遇到类似报错而且你的环境里同时存在多个 Codex 相关进程在后台运行可以先杀掉所有 Codex 进程再重试。WSL 环境里进程残留的情况很常见用pkill -f codex清理一下再重新运行大部分问题都能解决。这个报错看着吓人但你只要保持“先升级、再清缓存、后重登录”的排查顺序基本不会走到需要重装系统的地步。5.2 WSL needs updating 与 npm install 超时这两个问题我在准备环境时都遇到过本质上都是环境初始化阶段的问题但它们很容易让第一次接触 WSL 的人烦躁所以单独列一下。先说 WSL 版本过旧的问题。如果你的系统提示WSL needs updating. Your version of Windows Subsystem for Linux is too old.不要去手动下载什么补丁包直接在管理员终端里运行wsl --update如果更新之后还是提示版本过旧检查一下你的 Windows 版本。WSL2 的完整功能要求 Windows 10 版本 1903 以上或者 Windows 11。老系统上就算强行安装也会因为缺少虚拟化组件导致 WSL 无法启动。npm install 超时问题主要发生在国内网络环境下。除了我之前提到的换源方案还有一个技巧如果某个包始终在某个阶段下载失败不要反复重试同一份配置。先npm cache clean --force清理缓存然后重新执行安装。有时候是因为缓存了损坏的包导致校验失败。如果还是不行就检查一下当前网络是否稳定WSL 里用ping测一下网络连通性是一个简单有效的判断方法。5.3 node 版本过低导致的 CLI 安装失败这一点常常被别人忽视。Claude Code 官方网站明确要求 Node.js 版本不低于 18。如果你用 apt 装了老版本 Node比如 14 或 16npm 安装时虽然能下载包但运行时会直接报错。当时的报错信息是Error: The engine node is incompatible with this module.这其实是 npm 的保护机制在起作用意思是当前 Node 版本不兼容。解决办法就是用 nvm 装一个新版本nvm install 20 nvm use 20 node -v如果你已经用 nvm 安装了新版本但全局安装的 CLI 还是报错检查一下当前终端会话是否真的切换到了新版本。nvm 的切换只对当前 shell 生效新开一个窗口后需要重新nvm use。如果嫌麻烦可以直接在~/.bashrc里加一行nvm use 20 /dev/null 21这样每次打开 WSL 终端都会默认使用 Node 20。这个问题解决之后Claude Code 和 Codex 都能稳定运行。下面把这次遇到的报错整理成速查表报错特征常见原因处理方式WSL needs updatingWSL 内核或系统组件过旧wsl --update重启终端npm install 超时或下载缓慢默认源网络不稳定缓存损坏换镜像源清理 npm 缓存后重试ERROR: The engine node is incompatibleNode 版本低于 18通过 nvm 安装并使用 Node 20EACCES: permission deniednpm 全局目录权限不足设置用户级 npm prefix避免 sudocc switch local proxy failed while handling codex endpoint /responsesCodex 版本过旧或本地缓存异常升级 Codex清空~/.codex重新登录这张表是我这次实操中最常遇到的问题集合第二次遇到同类情况时照着跑一遍基本十分钟内能解决。6. 日常使用建议Codex 和 Claude Code 到底怎么分工6.1 把 VSCode 和 WSL 组合成日常入口配置完成后我需要一个舒服的日常使用姿势。最简单有效的方案是Windows 上装 VSCode然后安装 Remote-WSL 扩展。这个扩展能让 VSCode 直接打开 WSL 里的目录终端也会自动切换为 WSL 的 bash 环境。具体操作是VSCode 安装扩展在左下角选择“连接到 WSL”然后打开 WSL 里的项目文件夹。打开后按Ctrl ~呼出终端终端默认就是 bash。在这个终端里运行claude或codex两个工具都能正常工作。为什么推荐这个组合因为 Claude Code 和 Codex 都是终端交互式工具它们需要长时间占用一个终端窗口而 VSCode 的集成终端体验非常成熟分屏、滚动、快捷键都很顺手。同时VSCode 本身还能高亮显示 WSL 里的文件代码开发体验比纯终端好很多。如果你不想用 VSCode直接用 Windows Terminal 连接 WSL 也可以。Windows Terminal 对 WSL 的支持也很优秀和 VSCode 集成终端相比各有优势。我这里推荐 VSCode 是因为它把文件编辑和终端操作放在同一个界面里对日常编码效率提升更明显。6.2 两个工具在真实开发里各自最适合干什么经过这次安装配置我对 Claude Code 和 Codex 的分工有了比较清晰的认知。Claude Code 适合做“结对编程”。它的交互模式是对话式的你描述一个需求它会提出方案你确认之后它开始修改代码。整个过程你始终在上下文里可以随时提出新的建议或调整方向。它适合处理那些需要人类判断力和审美决策的任务比如重构一个模块、修改业务逻辑、写单元测试。Codex 适合做“任务代理”。它的交互模式更像“布置任务”你给它一个明确目标它会自己拆解然后连续执行多个命令。它更适合做那些目标明确、步骤可以被验证的任务比如配置环境、批量处理文件、执行 git 操作、跑测试并修复报错。我现在的习惯是简单的机械任务交给 Codex给它一个清晰的目标让它自己去跑复杂的、需要多次确认设计意图的编码任务交给 Claude Code我在旁边当评审。这样两个工具各司其职比自己一个人埋头敲命令要高效得多。如果你也想用这套组合我最后的建议是把这次记录的脚本和配置保存下来下次换机器或者重装环境时直接用 Codex 跑一遍完整流程。你会发现只要环境变量和依赖装好了一次后面的重复劳动成本几乎是零。我个人尝试下来最大的体会是AI 代操作这件事本质上是在和一个虚拟实习生协作。它干活快、不会累、不会抱怨但它需要明确的目标也需要有人在关键节点上把方向。那次让 Codex 帮我装 Claude Code 的经历让我更清楚地看到了 AI 代理在当前阶段的能力边界和真正价值。如果你也想试试记住一个下指令的小技巧目标要具体约束要写清楚最后给它一个可以验证的验收方式它能帮你省下很多时间。