配置 IDE 与 Windows / WSL2，避免装在错误宿主

同一个屏幕里，可能藏着两个不同的工作现场

你在 VS Code 里选中一个函数，Codex 却解释了旧副本。终端显示命令正常，保存文件又出现整页换行变化。

这不是一句“更仔细看上下文”能修好的问题。Windows、WSL2、编辑器扩展和仓库必须先画成一张宿主图。 看清它们在哪里，代码改动才有意义。

这节课要交付什么

这不是一份只需要读完的功能介绍。你要在真实但可控的环境中留下一个可以复查的结果，并且能回答三个问题：Codex 看到了哪些事实，它实际做了哪些动作，你用什么独立证据确认结果成立。

最终结果是：一个宿主、路径和 CODEX_HOME 都清楚的 IDE 集成环境。开始前先创建一份简短记录，把当前环境、目标、禁止动作和验收方式写下来。后面的命令、截图和修改都回到这份记录，不靠聊天窗口里的“应该已经好了”判断完成。

先看官方边界

官方 IDE 页面当前覆盖 VS Code、Cursor、Windsurf、VS Code Insiders、Xcode 与 JetBrains，并说明打开文件和选区会成为上下文。Windows 文档区分原生 PowerShell 沙箱与 WSL2 Linux 沙箱；WSL1 自 Codex 0.115 起不再支持。两边都能用不代表同一个任务应跨两个宿主混跑。

官方页面会随产品更新。教程引用的是当前可核对的能力与命令，不把界面位置、套餐权限或预览功能包装成永久承诺。你在自己的设备上看到不同按钮时，先核对官方页面和本机版本，再决定是否继续；不要用过期截图覆盖现场事实。

任务现场

仓库在 C 盘，编辑器用 Remote WSL 打开，终端里的 codex 却来自 Windows PATH。你选中一个函数，Codex 回答的却是另一路径下的旧副本。表面像上下文失灵，根因是编辑器、仓库和 CLI 不在同一个宿主。先画出三者关系，再决定原生 Windows 还是 WSL2。

先把现场写成四行：工作目录或项目、当前版本或输入、允许动作、完成证据。如果其中任何一行只能写“让 Codex 自己看”，说明上下文仍然不够具体。Codex 可以帮助检查，但不能替你决定哪些数据能上传、哪个生产动作已获授权，或一个异常是否可以忽略。

动手前准备

在 IDE 中安装官方扩展并记录扩展发布者。若选择 WSL2，使用 wsl --install 与 wsl --update 建立受支持环境，把练习仓库放在 ~/code，而不是 /mnt/c，以减少性能与权限问题。在 WSL 内按官方页面安装 Codex。需要共享配置时才显式设置 CODEX_HOME，并记录为什么共享。

把练习放在可恢复的位置，保留原始输入，并记录开始时的状态。涉及代码时先看版本控制状态；涉及数据时先复制脱敏样例；涉及外部服务时先使用只读或草稿模式。准备工作看似慢，却能让失败变成一次可以解释和回退的实验。

第一步：只读建立基线

先在 IDE 集成终端运行 pwd、which codex 和 codex --version；Windows PowerShell 则记录 Get-Location 与命令解析结果。把仓库路径、扩展宿主和 CLI 路径放在同一张表。三者不一致时不要继续写入，先重新用正确宿主打开仓库。

这一阶段不要急着要求“直接修好”。先让 Codex 复述目标、列出它实际读取的来源，并指出还缺哪些证据。你要检查它有没有打开正确目录、有没有把搜索摘要当原文、有没有把旧日志误当当前状态。基线不可信，后面的修改越多，返工成本越高。

第二步：限制范围后执行

打开一个测试文件，选中唯一的函数，只要求 Codex 解释选区并指出所在文件，不做修改。随后让它提出一个局部重命名方案，明确只改当前文件。批准后检查 diff，确认没有修改另一宿主中的副本，也没有因为路径大小写或换行符产生整文件变化。

执行指令应该同时包含目标、范围和停止条件。把“不要乱改”换成可观察边界，例如只允许修改两个文件、不安装依赖、不发送消息、不触碰生产数据。出现新的权限、需要改变既有契约或发现输入口径不一致时，要求 Codex 停下来报告，而不是自行选择更大的方案。

第三步：用独立证据验收

关闭并重新打开 IDE，在同一宿主恢复项目。再次检查路径、版本和选区上下文。WSL 环境额外记录 wsl --version、仓库是否位于 Linux 文件系统、CODEX_HOME 指向哪里；原生 Windows 则记录默认配置目录与沙箱模式。最后跑一个最小项目检查。

验收必须尽量脱离生成答案本身：安装类任务看版本、路径和真实启动结果；界面任务看目标视口与交互；数据任务用独立计算和异常清单；安全任务用原始复现、补丁 diff 与回归测试。把通过、失败和未验证分开记录，未验证不是失败，但绝不能伪装成通过。

完整案例

一个团队把前端仓库放在 /mnt/c，VS Code 使用 WSL 扩展，Codex CLI 却由 Windows npm 安装。保存文件时出现权限与换行噪声。团队先把练习副本移到 ~/code，在 WSL 内安装当前 CLI，确保 IDE 终端的 which codex 指向 Linux 路径，再完成单文件重命名。diff 从整文件变化缩成两行，问题因此可解释。

案例的重点不是复制同一句 prompt，而是观察决策顺序：先确定权威来源，再缩小动作面，最后让证据闭环。如果你的项目结构不同，保留这个顺序，替换文件名、命令和验收对象。任何会产生外部影响的步骤，都应在真正执行前再次获得明确授权。

故障诊所

扩展看不到选区时先确认当前窗口是否真的运行在期望宿主，并用一个短文本文件排除语言服务问题。WSL 性能慢时检查仓库是否位于 /mnt/c。WSL1 环境先升级，不在不支持版本上继续调参。配置不一致时比较 Windows 与 Linux 各自的 CODEX_HOME；共享目录不是越多越好，凭据和权限必须按组织规则处理。

恢复时一次只改变一个变量。先保存错误原文和当前状态，再判断问题属于安装路径、权限、上下文、实现还是验收环境。不要连续重装、重写和切换工具，因为那会抹掉因果关系。修复后重复最小复现，再跑相邻路径，确认没有用一个新问题遮住旧问题。

迁移练习

分别在原生宿主和 WSL2 建立两个无敏感信息的小目录，记录 IDE、终端和 Codex 看到的路径。选择其中一个作为正式工作方式，写出不选择另一个的理由、迁移步骤与回退方法。以后换编辑器时复用这张宿主表。

完成练习后，把其中的产品名和文件名遮住，只保留“输入—动作—证据—停止条件”。如果这四项仍能指导另一个任务，说明你学到的是方法；如果离开示例 prompt 就不会继续，回到任务现场，补出你真正依赖的判断规则。

选一个宿主，然后让所有证据回到那里

记录仓库位置、IDE 宿主、which codex、版本和 CODEX_HOME。只要其中一项跨到了另一个环境，就先停下写入。

最稳定的配置不一定功能最多，而是团队能复现、能解释、出错后知道从哪一层恢复。

完成检查

• 编辑器、仓库和 Codex CLI 位于同一预期宿主
• WSL2 仓库优先位于 Linux 文件系统
• 选区测试只影响了预期文件和行
• CODEX_HOME 是否共享有明确理由与安全边界
• 我保留了开始状态、实际动作和最终证据
• 我把失败、未验证和已通过分开记录
• 需要新权限或外部影响时，Codex 会停下来询问