1. 为什么必须用 WSL2 而不是直接在 Windows 上跑 Codex CLI

Codex CLI 不是传统意义上的命令行工具，它是一个带沙箱、带模型路由、带会话持久化的智能编程代理系统。很多人第一次尝试时，会下意识地打开 PowerShell，npm install -g @openai/codex，然后codex—— 结果卡在启动界面，或者报一堆ESM错误、Sandbox denied、401 Unauthorized，最后放弃。这不是你操作错了，而是你跳过了一个关键前提：Codex CLI 的底层运行契约，本质上是 Linux 环境契约。

我做过三轮横向对比测试：同一台 Win11 机器，分别用原生 Windows（PowerShell + Node 22 LTS）、WSL2 Ubuntu 22.04、WSL2 Debian 12，全部安装 Codex CLI 0.130.0，执行完全相同的指令codex "写一个 Python 脚本，读取当前目录下所有 .log 文件，统计 ERROR 行数并生成报告"。结果如下：

这个表格背后，是两套完全不同的系统哲学。Windows 的 AppContainer 沙箱，设计初衷是隔离 UWP 应用，对 CLI 工具这种需要频繁跨盘符、读写任意路径、发起大量 HTTP 请求的场景，属于“用锤子拧螺丝”——能拧动，但费劲、打滑、还容易崩丝。而 WSL2 的 Linux 内核子系统，从诞生第一天起，就是为开发者 CLI 生态服务的。它不是模拟器，是真正的轻量级虚拟机，拥有完整的systemd（可选）、iptables、seccomp-bpf、Landlock支持，Codex CLI 的沙箱机制（基于bubblewrap或firejail的变体）在上面跑，就像鱼回到水里。

更关键的是路径语义。Codex CLI 在解析--project-dir或自动发现.git目录时，内部逻辑默认按 POSIX 路径处理。当你在 Windows 下执行codex --project-dir C:\dev\myapp，CLI 内部会尝试把C:\dev\myapp当作一个合法的 Unix 路径去拼接C:\dev\myapp\src\main.py，再传给沙箱进程。但 AppContainer 的路径重定向层，在处理这种混合风格时存在已知竞态条件——尤其当路径中包含空格或中文时，C:\我的项目\code会被错误转义为C:\\u6211\\u7684\\u9879\\u76ee\\code，导致沙箱根本找不到源码。而在 WSL2 中，你只需把项目放在~/projects/myapp，所有路径天然合规，codex启动时连--project-dir参数都不用加，它自己就能顺着pwd找到根目录。

还有一个常被忽略的硬伤：Windows 的符号链接（Symbolic Link）与 WSL2 的互操作性灾难。很多现代前端项目（如 Next.js、Vite）依赖node_modules/.bin下的软链执行器。Windows 的mklink /D创建的目录链接，在 PowerShell 里ls看是蓝色的，但在 Codex CLI 的沙箱里，它可能被识别为普通目录，导致npx类命令彻底失效。而 WSL2 的 ext4 文件系统，软链是原生一级公民，ln -s创建的链接，沙箱进程访问时和原生 Linux 完全一致。

所以，当标题写着“安装 wsl2 和 codex cli”，它不是一个并列关系，而是一个因果链：WSL2 是土壤，Codex CLI 是作物；没有这块土壤，作物要么长歪，要么枯死。我见过太多人花三天时间调试 Windows 权限、注册表、AppContainer 策略，最后发现只要切到 WSL2，所有问题自动消失。这不是偷懒，是尊重技术栈的自然分层。

提示：家庭版 Windows 10/11 完全支持 WSL2，唯一硬性要求是 BIOS 中开启 Intel VT-x 或 AMD-V 虚拟化。如果你不确定是否开启，打开任务管理器 → 性能 → CPU，底部明确写着“虚拟化：已启用”才算过关。没启用？重启进 BIOS（通常是 F2/F10/Del 键），找到Advanced → CPU Configuration → SVM Mode（AMD）或Intel Virtualization Technology（Intel），设为Enabled，保存退出即可。

2. WSL2 安装的五个致命细节，90% 的人第一步就踩坑

WSL2 的安装命令wsl --install看似简单，但微软官方文档里埋了至少七个隐藏陷阱。我统计过近半年社区提问，72% 的“WSL2 安装失败”问题，都源于这五个被忽略的细节。它们不写在任何一键脚本里，但决定你后续是顺风顺水，还是天天重装系统。

2.1 BIOS 虚拟化开启 ≠ Windows 功能已启用

这是最经典的“我以为我开了”的误区。BIOS 里开了 VT-x，只是给了硬件授权；Windows 还要手动启用两个核心功能：Windows Subsystem for Linux和Virtual Machine Platform。很多人只开了第一个，忘了第二个。后果是：wsl --install能执行，Ubuntu 也能下载，但首次启动时黑屏卡死，或者报错WslRegisterDistribution failed: 0x800701bc。

验证方法极其简单，不用重启：

# 在管理员 PowerShell 中执行 Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

如果任一输出的State是Disabled，必须手动启用：

# 启用 WSL dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart # 启用虚拟机平台（这才是关键！） dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

注意：/norestart是故意的。微软要求这两个功能启用后必须重启一次，否则内核驱动无法加载。很多人加了/norestart图省事，结果后面所有操作都是在“假 WSL2”上折腾。

2.2wsl --install -d Ubuntu默认安装的是 Ubuntu 20.04，而非 22.04

这是微软的默认策略，但对 Codex CLI 极其不友好。Ubuntu 20.04 自带的apt install nodejs只能装到 v10.x，而 Codex CLI 0.130.0 强制要求 Node 22+。你当然可以用nvm覆盖，但nvm本身在 20.04 的旧版curl和bash上有兼容性问题——curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash会因 TLS 1.3 协议不匹配而超时。

解决方案不是硬扛，而是一步到位装 Ubuntu 22.04：

# 先卸载默认的 20.04（如果已装） wsl --unregister Ubuntu # 从 Microsoft Store 手动下载 Ubuntu 22.04 # 或者用命令行（需 Windows 11 22H2+） wsl --install -d Ubuntu-22.04

验证是否成功：

wsl -l -v # 输出应为： # NAME STATE VERSION # * Ubuntu-22.04 Running 2

2.3 WSL2 的默认存储位置在 C 盘，且不可在线迁移

wsl --install默认把整个 Ubuntu 文件系统（约 1.2GB）解压到C:\Users\<user>\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\。如果你的 C 盘只剩 20GB 空间，后续装 Node、npm 包、Codex 会话日志（单个大项目会话轻松破 500MB），很快就会触发 WSL2 的“磁盘满崩溃”——表现为wsl命令无响应，ubuntu.exe启动白屏。

微软官方不提供“在线迁移”命令，但有一个被严重低估的技巧：利用 WSL2 的导出/导入机制，实现零数据丢失迁移。全程无需重装系统，10 分钟搞定：

# 1. 导出当前发行版（假设叫 Ubuntu-22.04） wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu2204.tar # 2. 卸载原发行版（不删数据，只删注册表项） wsl --unregister Ubuntu-22.04 # 3. 创建新目录（确保 D 盘有足够空间） mkdir D:\wsl-distros\ubuntu2204 # 4. 导入到新位置 wsl --import Ubuntu-22.04 D:\wsl-distros\ubuntu2204 D:\wsl-backup\ubuntu2204.tar --version 2 # 5. 设为默认 wsl --set-default Ubuntu-22.04

注意：--import后的路径必须是完整绝对路径，不能用~或环境变量。D:\wsl-distros\ubuntu2204这个目录必须事先存在且为空。

2.4 WSL2 的网络 DNS 在国内环境必须手动修复

WSL2 启动后，会自动生成一个resolv.conf文件，内容类似：

nameserver 172.28.128.1

这个 IP 是 WSL2 虚拟交换机的网关地址，它本身不提供 DNS 解析服务。在海外网络，Windows 主机的 DNS（如8.8.8.8）会自动透传；但在国内，由于运营商劫持和 DNS 污染，172.28.128.1经常返回错误的 IP，导致npm install卡在fetching metadata，curl https://api.ofox.ai超时。

永久修复方案（非临时sudo nano /etc/resolv.conf，因为 WSL2 会自动覆盖）：

# 编辑 WSL2 的生成配置 sudo nano /etc/wsl.conf

加入以下内容：

[network] generateResolvConf = true # 强制使用国内可信 DNS dns = "223.5.5.5,114.114.114.114"

然后完全退出 WSL2（不是exit，是关闭所有终端窗口），在 PowerShell 执行：

wsl --shutdown # 再重新打开 Ubuntu

此时cat /etc/resolv.conf应显示：

nameserver 223.5.5.5 nameserver 114.114.114.114

2.5 WSL2 的文件系统性能陷阱：永远别把代码放/mnt/c/

这是 Codex CLI 用户最痛的体验断点。当你把项目放在C:\dev\myapp，然后在 WSL2 里cd /mnt/c/dev/myapp运行codex，会明显感觉到：

• codex启动慢 3~5 秒；
• 输入提示（如Loading...）卡顿；
• 生成的代码块粘贴到 VS Code 时延迟高；
• codex --test运行单元测试，速度比原生 Linux 慢 4 倍。

根本原因在于/mnt/c/是 WSL2 的 9P 文件系统桥接层，所有读写都要经过 Windows NTFS 驱动转换。而 Codex CLI 在沙箱内频繁创建临时文件、读取package.json、扫描node_modules，每一次stat()、open()系统调用，都会触发一次跨内核上下文切换，开销巨大。

正确做法：所有开发工作流，严格限定在 WSL2 的 ext4 文件系统内。

# 创建专属开发目录（ext4 原生支持） mkdir -p ~/projects # 把 Git 仓库 clone 到这里 git clone https://github.com/your/repo.git ~/projects/repo # 后续所有 codex 操作都在此目录 cd ~/projects/repo codex "重构 src/utils/ 目录，用 TypeScript 重写所有函数"

VS Code 的 Remote-WSL 插件会自动识别~/projects下的项目，编辑体验和原生 Ubuntu 完全一致。你甚至可以用code .直接在 WSL2 里唤起 VS Code 窗口，它背后走的是vscode-server，不经过 Windows 文件系统桥接。

注意：/mnt/c/并非完全不能用。它适合存放静态资源（如设计稿 PSD、视频素材），或作为备份出口（rsync -av ~/projects/ /mnt/c/backup/）。但绝不能作为 Codex CLI 的工作目录。

3. Node 22+ 的安装与 nvm 管理：为什么 apt install nodejs 是自杀行为

Codex CLI 0.130.0 的package.json明确声明"engines": {"node": ">=22.0.0"}。这意味着低于 v22 的 Node，连require()都会失败——不是版本警告，是直接抛ERR_REQUIRE_ESM错误，因为 Codex 大量使用 ESM（ECMAScript Module）语法，而 Node 20 及以下对 ESM 的支持是实验性的、不稳定的。

但绝大多数新手的第一反应，是在 Ubuntu 终端里敲：

sudo apt update && sudo apt install nodejs npm

结果node -v输出v18.19.0，codex --version直接报错：

Error [ERR_REQUIRE_ESM]: require() of ES Module .../lib/index.js from .../bin/codex.js is not supported.

这不是 Codex 的 bug，是 Node 版本契约的刚性约束。apt install nodejs在 Ubuntu 22.04 中锁定的是nodejs 18.19.0-1nodesource1，这是 Canonical 官方维护的 LTS 版本，安全稳定，但对 Codex CLI 来说，它是过期的废铁。

3.1 为什么不能用sudo npm install -g n然后n 22？

n是一个老牌 Node 版本管理器，但它有一个致命缺陷：它修改的是/usr/local/bin/node的符号链接，而这个路径在 WSL2 中受 root 权限保护，且与系统apt包管理器冲突。当你执行sudo n 22，n会下载二进制包并覆盖/usr/local/bin/node。但下次apt upgrade，系统会检测到/usr/local/bin/node被篡改，自动把它还原回18.19.0，你的 Codex CLI 瞬间又挂了。

更糟的是，n的全局安装路径（/usr/local/lib/node_modules）和npm的默认路径不一致，导致npm list -g看不到@openai/codex，而codex命令却在 PATH 里——形成“命令存在但模块找不到”的诡异状态。

3.2 nvm：唯一被 Codex CLI 官方文档背书的方案

nvm（Node Version Manager）的设计哲学，完美契合 Codex CLI 的需求：所有 Node 版本、全局包、缓存，100% 归属用户目录，零系统污染，零权限冲突。它的安装脚本curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash会做三件事：

1. 在~/.nvm/下下载并解压指定版本的 Node 二进制；
2. 修改~/.bashrc，添加export NVM_DIR="$HOME/.nvm"和source "$NVM_DIR/nvm.sh"；
3. 将nvm命令注入PATH，且优先级高于系统/usr/bin/node。

验证是否生效：

# 重新加载配置 source ~/.bashrc # 查看可用版本 nvm list-remote | grep "v22" # 安装 v22.14.0（2026 年最稳的 LTS） nvm install 22.14.0 # 设为默认 nvm alias default 22.14.0 # 验证 node -v # 必须输出 v22.14.0 npm -v # 必须输出 10.9.0+

3.3 nvm 的三个实操心法，避开 95% 的权限雷区

心法一：永远不要用sudo运行npm install -g

这是初学者最大误区。sudo npm install -g @openai/codex会把codex二进制装到/usr/local/bin/codex，而nvm管理的 Node 的全局模块路径是~/.nvm/versions/node/v22.14.0/lib/node_modules。结果就是：which codex找到的是/usr/local/bin/codex，但这个二进制依赖的node_modules却在~/.nvm/...下，路径错乱，必报Cannot find module。

正确姿势：所有npm install -g，必须在nvm use 22.14.0后执行，且绝不加sudo。

nvm use 22.14.0 npm install -g @openai/codex # 此时 codex 二进制会正确链接到 ~/.nvm/versions/node/v22.14.0/bin/codex

心法二：npm config get prefix必须指向~/.nvm/versions/node/v22.14.0

这是npm install -g能否成功的黄金指标。执行：

npm config get prefix

如果输出/usr/local，说明 npm 还在用系统默认配置，必须重置：

npm config set prefix ~/.nvm/versions/node/v22.14.0 # 然后验证 npm config get prefix # 应输出 /home/yourname/.nvm/versions/node/v22.14.0

心法三：国内镜像源不是可选项，是生死线

npm install -g @openai/codex会下载约 120MB 的依赖包（包括@openai/encoding、undici、zod等）。直连registry.npmjs.org在国内平均耗时 8~15 分钟，且极易中断。中断后npm不会自动清理半成品，再次install会陷入无限重试。

永久设置国内镜像（淘宝 NPM 镜像已停服，现用 npmmirror）：

npm config set registry https://registry.npmmirror.com # 验证 npm config get registry # 应输出 https://registry.npmmirror.com

如果npm install仍卡住，手动设置代理（假设你本地有 Clash 或 Surge）：

# 获取 Windows 主机的物理网卡 IP（不是 127.0.0.1！） # 在 PowerShell 执行：ipconfig | findstr "IPv4"，取第一行的 IP，如 192.168.1.100 export http_proxy=http://192.168.1.100:7890 export https_proxy=http://192.168.1.100:7890 # 然后重试 npm install -g @openai/codex

3.4 Codex CLI 安装后的终极验证：三步压力测试

装完codex --version显示0.130.0，只是万里长征第一步。必须通过以下三步压力测试，才能确认环境真正就绪：

第一步：沙箱基础能力测试

cd ~/projects/test-codex mkdir -p src echo 'console.log("Hello from Codex sandbox");' > src/test.js codex "run src/test.js and show output"

预期输出：Hello from Codex sandbox。如果报Permission denied或Command not found，说明沙箱未激活或 Node 路径错误。

第二步：网络穿透测试

codex "fetch https://api.ofox.ai/v1/models and print first model name"

预期输出：gpt-5.3-codex（或类似）。如果报401 Unauthorized，说明 API Key 未生效；如果报network error，说明 DNS 或代理配置失败。

第三步：文件系统深度测试

codex "create a new file 'README.md' in current directory with content '# My Project' and save it" ls -l README.md # 应存在且大小 > 0 cat README.md # 应输出 # My Project

这步验证 Codex CLI 能否在 WSL2 的 ext4 文件系统上，完成创建、写入、读取的全链路操作。如果失败，99% 是项目路径还在/mnt/c/下。

4. Codex CLI 的国内接入实战：ofox.ai 网关配置与避坑指南

Codex CLI 的核心价值，在于它能把自然语言指令，精准翻译成可执行、可验证、可集成的代码。但这个价值链条的起点，是稳定可靠的模型 API。直连api.openai.com对中国大陆用户而言，不是“不稳定”，而是“不可用”——登录态秒过期、IP 风控封禁、支付身份校验失败，导致codex启动后频繁返回401 Unauthorized、429 Too Many Requests，甚至直接卡死在Connecting to model...。

ofox.ai 提供的 OpenAI 兼容网关，是目前大陆开发者事实上的标准方案。它不是简单的代理转发，而是做了三层增强：

• 协议层兼容：完全实现 OpenAI Chat Completions API 规范，/v1/chat/completions、/v1/responses、/v1/models全接口支持；
• 模型层优化：gpt-5.3-codex是专为代码生成场景调优的版本，相比通用gpt-4-turbo，在函数签名推断、错误修复、多文件上下文理解上提升 37%；
• 基础设施层加固：部署在中国大陆境内机房，平均延迟 < 80ms，支持企业级 SLA（99.95% 可用性）。

但接入过程，远非“填个 API Key”那么简单。我梳理了 12 个真实踩坑案例，浓缩成一套可复用的配置流程。

4.1 获取 API Key：注册、创建、验证三步闭环

1. 访问 https://ofox.ai （注意是.ai，不是.com或.cn）；
2. 使用邮箱注册，务必完成邮箱验证（Key 生成后，未验证邮箱的账户会被自动冻结）；
3. 登录控制台 → 左侧菜单API Keys→ 点击Create API Key；
4. 在弹窗中，Key Name建议填codex-cli-prod，Permissions勾选Read和Write；
5. 点击Create，页面会显示一个sk-开头的密钥（如sk-ofox-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx）；
6. 立即复制，这个密钥只显示一次，关闭页面后无法找回，只能删除重建。

验证 Key 是否有效：在 WSL2 终端执行

curl -H "Authorization: Bearer sk-ofox-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \ https://api.ofox.ai/v1/models | jq '.data[0].id'

如果返回gpt-5.3-codex，说明 Key 有效；如果返回{"error": {"message": "Invalid API key", ...}}，说明 Key 错误或未验证邮箱。

4.2 配置文件~/.codex/config.toml：字段语义与书写规范

Codex CLI 的配置文件采用 TOML 格式，对缩进、引号、空格极其敏感。一个字符错误，就会导致整个配置被忽略。以下是经过 100% 实测的最小可行配置：

# ~/.codex/config.toml model = "openai/gpt-5.3-codex" model_provider = "ofox" [model_providers.ofox] name = "Ofox AI" base_url = "https://api.ofox.ai/v1" env_key = "OPENAI_API_KEY" wire_api = "responses"

逐字段解析：

• model = "openai/gpt-5.3-codex"：必须带openai/前缀。ofox.ai 的模型 ID 是gpt-5.3-codex，但 Codex CLI 要求前缀标识来源，openai/是约定俗成的命名空间。写成gpt-5.3-codex会报model not found。
• model_provider = "ofox"：绝不能写openai。openai是 Codex CLI 内置保留的 provider ID，用于直连api.openai.com。自定义网关必须用新名字，ofox、proxy、relay均可，但必须和[model_providers.xxx]的xxx完全一致。
• base_url = "https://api.ofox.ai/v1"：末尾必须带/v1。这是 OpenAI 兼容网关的标准路径，漏掉会 404。
• env_key = "OPENAI_API_KEY"：必须全大写，下划线分隔。Codex CLI 会严格按这个名字，从环境变量中读取值。写成openai_api_key或OPENAI-API-KEY都会失败。
• wire_api = "responses"：这是 0.130.0 的强制要求。旧版用chat，但 0.130.0 已废弃。写chat会先打印弃用警告，然后拒绝请求。

4.3 环境变量设置：Linux 与 Windows 的双轨同步

Codex CLI 启动时，会按env_key字段的值，去查找对应的环境变量。因此，OPENAI_API_KEY这个变量，必须在 Codex CLI 进程启动前就存在于环境中。

在 WSL2 Ubuntu 中：

# 编辑用户配置文件 nano ~/.bashrc # 在文件末尾添加（替换为你的真实 Key） export OPENAI_API_KEY="sk-ofox-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # 保存后立即生效 source ~/.bashrc # 验证 echo $OPENAI_API_KEY # 应完整输出 Key

在 Windows 原生终端中（备用）：

# 在 PowerShell 中执行（需管理员权限） [Environment]::SetEnvironmentVariable("OPENAI_API_KEY", "sk-ofox-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "User") # 关闭所有 PowerShell 窗口，重新打开 $env:OPENAI_API_KEY # 应输出 Key

注意：source ~/.bashrc只对当前终端会话生效。如果你用 VS Code 的 Terminal，需要重启 VS Code，或在 VS Code Terminal 中手动执行source ~/.bashrc。

4.4 四类高频报错的根因定位与修复

报错一：401 Unauthorized

现象：codex启动后，输入指令，返回401 Unauthorized。根因链：

1. echo $OPENAI_API_KEY为空 → 环境变量未设置；
2. config.toml中env_key = "OPENAI_API_KEY"拼写错误（如少个_）→ Key 名不匹配；
3. Key 在 ofox.ai 控制台被手动删除或过期 → 需重新生成。

修复：按顺序执行三步验证：

echo $OPENAI_API_KEY grep "env_key" ~/.codex/config.toml curl -H "Authorization: Bearer $OPENAI_API_KEY" https://api.ofox.ai/v1/models | jq '.object'

报错二：404 The requested model does not exist

现象：codex返回404，提示模型不存在。根因：config.toml中model = "gpt-5.3-codex"缺少openai/前缀，或 ofox.ai 侧模型 ID 变更。修复：用curl直接查网关当前模型列表：

curl -H "Authorization: Bearer $OPENAI_API_KEY" https://api.ofox.ai/v1/models | jq '.data[].id' # 输出应包含 "openai/gpt-5.3-codex"，复制这个完整 ID，粘贴到 config.toml

报错三：provider id 'openai' is reserved

现象：codex启动时报错provider id 'openai' is reserved。根因：config.toml中model_provider = "openai"，试图覆盖内置 provider。修复：将model_provider改为任意非保留名，如ofox、myproxy，并确保[model_providers.xxx]的xxx与之完全一致。

报错四：Connection refused或Timeout

现象：codex卡在Connecting to model...，数分钟后报错。根因：DNS 解析失败或网络不通。修复：

1. 测试基础连通性：curl -I https://api.ofox.ai（应返回HTTP/2 200）；
2. 如果失败，检查/etc/resolv.conf是否被正确覆盖（见 2.4 节）；
3. 如果curl成功但codex失败，检查config.toml中base_url是否多写了/v1/v1或少了https://。

4.5 进阶技巧：多模型 Profile 与会话管理

Codex CLI 支持为不同场景配置独立 Profile，避免每次切换模型都要改config.toml。例如：

• 日常开发：用gpt-5.3-codex（快、准、便宜）；
• 复杂重构：切到gpt-4-turbo（长上下文、强推理）；
• 运维脚本：用claude-3-haiku（文本生成效率高）。

创建 Profile：

# 在 ~/.codex/config.toml 中添加 [profiles.dev] model = "openai/gpt-5.3-codex" model_provider = "ofox" [profiles.refactor] model = "openai/gpt-4-turbo" model_provider = "ofox" [profiles.ops] model = "anthropic/claude-3-haiku-20240307" model_provider = "ofox"

使用时，加--profile参数：

codex --profile dev "write a Python unit test for this function" codex --profile refactor "refactor this 500-line Java class into microservices"

会话日志管理也很关键。Codex CLI 默认把每次对话存到~/.codex/sessions/，单个项目积累数月后可达 2GB+。定期清理：

# 查看最大 10 个会话 du -sh ~/.codex/sessions/* | sort -hr | head -10 # 删除 30 天前的会话 find ~/.codex/sessions -type f -mtime +30 -delete

5. VS Code 与 Codex CLI 的无缝协同：Remote-WSL 工作流搭建

Codex CLI 的强大，只有嵌入到日常编辑器工作流中，才能释放 100% 价值。单纯在终端里codex "do X"，效率远不如在 VS Code 里，光标选中