1. 为什么我最后把 Codex 搬进了 WSL如果你最近在折腾 Codex大概率会遇到一个很现实的问题Windows 原生下能跑但跑得不够舒服。官方 CLI 页面写得很清楚Windows 目前处于实验阶段翻译成人话就是「能启动但别指望它每次都听话」。我自己在 PowerShell 里装完openai/codex之后最直观的感受是 npm 全局包的路径偶尔会抽风codex命令时有时无重装一次 Node 又得重新配环境变量折腾半天代码没写几行。WSL 的好处在这里就体现出来了。它本质上是跑在 Windows 里的一个完整 Linux 环境包管理、命令行工具链、Node 版本切换都是 Linux 那套成熟玩法。Codex 作为一个终端优先的工具在 Linux 下的行为更可预测npm i -g装到哪、which codex指向谁、配置文件放在~/.codex/还是项目目录全都清清楚楚。适合谁适合准备认真用 Codex 跑连续任务的人比如批量改代码、配深度学习环境、长时间多窗口操作如果你只是想点开网页聊两句那原生 Windows 也够用。这篇就按「WSL 里从零到能跑通一次请求」的路径来写中间会给出可复制的settings.json和config.toml骨架并且用 TaoToken 统一 Key 和 API 通道省得你在多个平台之间来回切。Node.js 和 npm 的环境差异是重点因为十有八九的报错都出在这一层。2. 前置准备WSL、Node.js 与 TaoToken 通道2.1 WSL 安装与磁盘位置以管理员身份打开 PowerShell执行wsl --install装完按提示设置 Linux 用户名和密码重启。之后在 cmd 或 PowerShell 里直接输入wsl就能进 Linux 终端。这里有个坑要提前说默认安装会把 WSL 放在 C 盘C 盘本来就不宽裕再塞一个发行版容易让它变成「情绪盘」。可以后续用wsl --export和wsl --import迁移到 D 盘或者直接让 Codex 帮你操作这类系统级任务它处理得挺稳。2.2 Node.js 用 nvm 管别用 aptCodex CLI 依赖 Node 环境而 WSL 里装 Node 最省心的方式是 nvm不是apt install nodejs。apt 源里的 Node 版本往往偏旧而且和 npm 的全局路径容易打架。先装 curlsudo apt-get update sudo apt-get install curl -y然后装 nvmcurl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash装完先验证command -v nvm如果没反应别怀疑人生把终端关掉重开再试。这是 nvm 写进.bashrc后需要重新加载的典型表现。接着装 LTSnvm install --lts nvm use --lts node --version npm --version which node which npmwhich node的输出应该是~/.nvm/versions/node/vXX/bin/node这种路径。如果它指向/usr/bin/node说明系统里还有另一个 Node后面npm i -g装出来的codex可能不在 PATH 里这是 WSL 下最常见的「命令找不到」根因。2.3 TaoToken 的定位与 Key 获取TaoToken 在这里扮演的是统一入口你不需要为每个模型或工具单独配一套 Key 和 Base URL而是用同一个 API 通道去接。对 Codex 这种需要频繁发请求的 CLI 来说统一通道的好处是配置只写一次换模型或换项目时改的只是模型名。先到官网了解整体能力https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 然后在控制台创建 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。Key 建议直接写进环境变量别硬编码进配置文件后面会演示。3. 可复制配置settings.json 与 config.toml 骨架3.1 安装 Codex CLI在 WSL 终端里执行npm i -g openai/codex codex --version升级用npm i -g openai/codexlatest如果codex --version报 command not found先npm config get prefix看全局路径再确认这个路径在echo $PATH里。nvm 环境下 prefix 通常是~/.nvm/versions/node/vXX一般不会有问题出问题的多半是前面提到的系统 Node 混用。3.2 环境变量把 Key 和 Base URL 抽出来在~/.bashrc末尾追加export TAOTOKEN_API_KEYsk-你的Key export OPENAI_API_KEY$TAOTOKEN_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api然后source ~/.bashrc。把OPENAI_API_KEY指向同一个值是为了兼容那些默认读 OpenAI 变量的工具OPENAI_BASE_URL指向 TaoToken 的 API 地址注意这里不加 UTM 参数保持干净。3.3 config.toml 骨架Codex 的配置文件放在~/.codex/config.toml。下面是一个可用的骨架# ~/.codex/config.toml model gpt-5-codex provider taotoken [providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [profiles.default] model gpt-5-codex provider taotoken approval_policy on-request几个参数说明base_url决定请求发到哪env_key告诉 Codex 从哪个环境变量读 Key这样配置文件里不出现明文。approval_policy设成on-request表示执行有副作用的命令前会问你跑批量任务时更安全。3.4 settings.json 骨架有些 IDE 插件或周边工具读的是settings.json放在项目根目录或~/.codex/下都行{ codex.provider: taotoken, codex.baseUrl: https://taotoken.net/api, codex.apiKeyEnv: TAOTOKEN_API_KEY, codex.model: gpt-5-codex, codex.autoApprove: false, codex.timeoutMs: 120000 }autoApprove保持 false等确认流程跑通再考虑放开。timeoutMs给到 120 秒是因为长上下文任务偶尔会超过默认的 60 秒。4. 验证请求从一次对话到一次真实改动4.1 最小验证发一条请求配置写完后先做最小验证。在 WSL 终端里codex 用一句话解释什么是 WSL如果配置正确你会看到 Codex 通过 TaoToken 通道返回结果。这一步能过说明 Key、Base URL、模型名三者对上了。如果卡住或报 401先echo $TAOTOKEN_API_KEY确认变量非空再检查config.toml里的env_key拼写。4.2 验证模型通道想单独确认模型侧是否正常可以直接用模型对话页面发一条测试https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。在网页里发一句「你好」能正常回就说明账号和通道没问题剩下的就是本地 CLI 配置的事。这种分层排查能帮你快速定位问题在通道还是在本地。4.3 验证真实改动让它改一个文件建个测试目录mkdir -p ~/codex-test cd ~/codex-test echo print(hello) demo.py codex 把 demo.py 改成打印 hello wslCodex 会读取文件、给出修改建议按提示确认后写回。跑完cat demo.py看结果。这一步验证的是完整链路读文件、调模型、写回磁盘。能跑通说明 WSL 下的 Codex 已经可用。4.4 长期编码场景如果你打算把 Codex 当成日常编码搭子频繁跑多轮任务可以了解下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。它更适合长时间、多会话的编码工作流和单次验证是两种用法。5. 本篇常见错排查5.1 codex: command not found九成是 Node 路径问题。先which node和which npm确认都指向 nvm 目录。如果指向/usr/bin说明系统 Node 在抢路。解决方式是nvm use --lts后重开终端或者把 nvm 的初始化段确认写进了.bashrc。另一个可能是npm i -g时装到了别的 prefix用npm config get prefix核对。5.2 401 或 invalid api key先echo $TAOTOKEN_API_KEY空的话说明.bashrc没生效source一下。非空还报 401检查 Key 是否复制完整、有没有多余空格。再确认config.toml里env_key写的是TAOTOKEN_API_KEY而不是别的名字。如果都不对去控制台重新生成一个 Keyhttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。5.3 请求超时或连接被拒先确认base_url是https://taotoken.net/api没有多余斜杠或路径。WSL 的网络一般继承 Windows如果 Windows 侧有防火墙或安全软件拦截也会表现为超时。可以先用curl -I https://taotoken.net/api看能否通通不了就是网络层的事和 Codex 无关。5.4 npm 装包慢或卡住WSL 下 npm 默认源在部分网络环境会慢。可以换源npm config set registry https://registry.npmmirror.com换完再npm i -g openai/codexlatest。如果之前装了一半失败先npm uninstall -g openai/codex再重装避免残留的半成品包干扰。5.5 配置文件不生效Codex 读配置有优先级项目目录 用户目录。如果你在项目里放了config.toml它会覆盖~/.codex/config.toml。排查时先确认当前目录有没有同名文件。另外 TOML 对缩进和引号敏感base_url的值必须带引号写错了会静默忽略整段。6. 接入文档与后续动作配置跑通之后建议把接入文档过一遍里面有针对不同工具的参数说明和示例https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。尤其是当你后面要接 Claude Code 这类工具时文档里的通道配置能直接复用https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。我自己的习惯是WSL 里只维护一份~/.codex/config.tomlKey 走环境变量项目里最多放一个覆盖模型名的局部配置。这样换项目时不用重复填 Key也不会把敏感信息提交进 Git。跑通第一次请求之后先拿一个小文件试改动确认写回没问题再放开去跑批量任务。这套流程走下来WSL 下的 Codex 确实比 Windows 原生顺手不少至少不用再跟 npm 的全局路径斗智斗勇了。