Windows 上怎么使用 Codex
Windows 上使用 Codex，关键不是找到一条能运行的安装命令，而是选定环境并保持路径、依赖、凭证和命令一致。你可以使用原生 PowerShell，也可以在 WSL2 中按 Linux 方式工作。两者都能用，但不要把同一个项目的工具链拆在两个环境里却期待行为完全相同。
原生 PowerShell
安装官方 CLI 后，打开新的 PowerShell 窗口，运行：
codex --version
codex login status
cd C:\work\your-project
codex如果 codex 找不到，使用 Get-Command codex 查看是否安装以及实际路径。若版本不是预期版本，检查是否有多个安装来源。环境变量要在启动 Codex 的同一个进程链中存在；在另一个窗口设置变量，不会改变已经运行的应用。
WSL2
选择 WSL2 后，把项目、Node/Python 依赖和命令尽量放在 Linux 文件系统中，例如 ~/code/project。Windows 路径 /mnt/c/... 可以访问文件，但跨文件系统读写、权限和性能表现可能不同。先在 WSL 中运行 command -v codex、codex --version，再进入项目启动。
cd ~/code/project
codex --version
codex不要在 PowerShell 安装一套依赖、在 WSL 启动另一套项目，再用结果判断 Codex 本身有问题。先确认你到底在哪个环境运行。
路径和环境变量
配置文件位于当前用户的 Codex 目录。自定义 provider 时，使用环境变量名引用密钥，避免把真实值写入 config.toml。在 PowerShell 中可用 $env:NAME 检查当前会话是否有变量；不要打印变量内容。WSL 中的变量需要在 Linux shell 内设置，除非你明确配置了环境继承。
Windows 沙箱和权限
官方配置说明提供 Windows 原生沙箱字段。权限不足时，先确认目录 ACL、当前用户、终端权限和 Codex 沙箱设置。不要默认以管理员身份运行全部任务；先只给需要的目录写权限，生产目录和含密钥目录应单独隔离。
常见问题
command not found 查 PATH；路径格式错误查当前 shell；依赖找不到查安装环境；401 查变量和 Key 归属；403 查账户或组织策略；文件写入失败查目录权限和沙箱。把 PowerShell 或 WSL 的完整环境混在一条诊断记录里，往往会让问题更难定位。
完成 Windows 安装后，按Codex使用教程完成只读任务，再看Codex CLI 命令大全。
先选环境，再安装项目依赖
如果仓库已有 Windows 开发说明，先沿用团队实践；若项目日常只在 Linux 中开发，WSL 可能更容易保持命令一致。选择时看项目依赖和协作方式，不要仅根据某篇教程说哪一种“更快”。本文没有对不同机器做性能测试，也不把环境选择写成统一结论。
可以先在目标环境运行项目原本的启动和测试命令，确认没有 Codex 时也能工作。若项目本身无法运行，先保存基线错误，再让 Codex 参与排查。否则很难分辨问题来自模型修改还是已有环境。第一次任务最好在小仓库中完成，确认路径和工具都正常后再进入大项目。
官方原生 CLI 安装方式
OpenAI CLI 快速开始提供 Windows PowerShell 的安装选项。执行前核对脚本来源和当前说明，组织设备按管理员规定安装；不要把 Linux 的 curl ... | sh 原样粘贴到 PowerShell，然后根据语法错误判断产品不支持 Windows。
安装之后关闭旧终端，打开新窗口检查版本和命令位置。如果 Get-Command codex 没有结果，先检查安装输出与 PATH；如果返回多处，确认当前实际调用的入口。卸载前保存必要配置，不要把清空个人目录当作默认修复步骤。
安装成功后的第一条任务可以是“读取这个测试目录的 README，只总结内容，不修改文件”。它能帮助你验证工具读取和返回路径，不依赖 Web 服务、数据库或复杂构建。如果这一步失败，先查基础连接与权限，不需要立即修改真实项目。
PowerShell 安装命令示例
OpenAI 官方 README当前列出的命令如下。它会下载并执行官方安装脚本，执行前应核对来源；组织设备遵循组织安装方式。
powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"这是安装器的调用示例，不是要求永久修改系统执行策略。安装后重新打开终端，按前述步骤检查命令位置和版本。若失败，保存具体输出，先判断失败属于下载、执行还是写入环节，再处理对应条件。
在 PowerShell 中处理路径
Windows 路径可能含空格，命令中需要按 PowerShell 的引用规则处理。先手动进入项目目录，再启动 Codex，能减少工作目录歧义。任务里引用文件时，尽量使用仓库相对路径，并说明你指的是哪个子项目，不必把整台电脑的个人路径贴进提示词。
项目若位于同步盘、共享盘或受管目录，还可能遇到文件锁定与权限问题。先在同一目录做一个可撤销的小文件读写测试，确认失败是否与位置有关。不要为了绕过权限把生产材料随意复制到公共目录，也不要在没有备份的情况下移动整个仓库。
一些项目脚本包含 Bash 专用语法，在 PowerShell 中会失败。看到脚本报错时检查它声明的运行方式，选择项目支持的 shell。Codex 能提出命令，不等于系统已经安装了命令所需工具。把依赖和运行时信息写清楚，工具才知道该沿用哪条路径。
WSL 用户需要关注的边界
WSL 使用自己的 Linux 环境，里面的用户名、主目录、运行时和配置文件可能与 Windows 不同。先在 WSL 内确认 pwd、command -v codex 和版本，再检查项目依赖。不要把 Windows 中的安装目录硬编码到 Linux 配置，除非确实了解这种调用方式。
项目放在 Linux 文件系统后，编辑器可使用相应远程工作方式；如果使用 Windows 应用直接访问文件，检查它是否正确进入 WSL 环境。桌面端选择项目与终端 cd 到项目，是两种操作，需要分别确认实际路径。界面里显示相同项目名不足以说明访问了同一副本。
跨系统运行还可能遇到换行符、可执行位和大小写问题。把这些当作环境兼容问题检查，不要为了让某条命令通过就一次修改整个仓库的文件属性。先定位受影响文件，按照项目约定处理，并查看 diff 是否出现无关格式变化。
浏览器登录与终端回调
第一次启动需要认证时，按照当前客户端提供的方式登录。浏览器完成页面步骤以后，回到终端确认会话是否继续，不要提前关闭正在等待的窗口。如果认证失败，保留错误类型和发生阶段，按官方鉴权说明核对。
网络代理、企业访问策略和本机回调都可能影响认证流程，但不应在没有证据时归因。不要关闭整台电脑的安全设置来尝试登录，也不要公开完整回调地址或凭证文件。个人和组织账户并存时，先确认所选身份是否有目标功能和项目权限。
API 环境变量只对对应进程生效
PowerShell 设置当前会话变量，与通过系统设置保存长期变量，是不同操作。当前会话中的变量一般用于之后启动的子进程；已经运行的桌面应用不能据此假定自动更新。重启应用后再做最小请求，确认真正使用的账户和模型。
WSL 内应按 Linux shell 设置变量，不要因为 PowerShell 能看到值就跳过检查。变量存在也不代表 Key 有效。只检查是否存在即可，避免把值输出到录屏、日志和聊天记录。如果需要轮换，先在凭证所属平台操作，再更新对应启动环境。
第三方模型与 ClawSocket
完成基础客户端验收后，可以前往 ClawSocket 控制台核对可用模型。本站接入地址为 https://api.clawsocket.com/v1，凭证使用 ClawSocket 账户提供的 Key。不要把它与 OpenAI 登录、Kimi 官方平台或 GLM 编程套餐的密钥混用。
配置文件按当前用户和当前系统环境读取。Windows 原生与 WSL 内可能各有一份，因此改动前先确认正在运行哪一个 CLI。接入后验证文本、只读工具和可撤销修改，再检查服务端请求记录。具体模板见DeepSeek、Kimi、GLM 接入教程。
IDE、桌面端与终端结果不同怎么办
先比较三个入口的项目路径、客户端版本、配置文件和环境变量。不要同时重装扩展、删除配置并更换模型；每次只改一个条件。记录哪一入口可以完成相同小任务，哪一入口失败，能把问题缩到环境继承或入口配置。
IDE 的集成终端也不一定与外部 PowerShell 完全一致，特别是远程或 WSL 工作模式。查看编辑器当前工作环境，再执行普通项目命令。若命令本身失败，先解决运行时问题；若命令正常、模型请求失败，继续检查凭证、网络和 provider。
一次真实任务如何验收
选一个你熟悉的功能，给出复现步骤、目标文件和预期结果。要求先只读定位，再小范围修改，最后运行项目已有验证。检查改动中有没有无关换行、路径或依赖变更，命令是否确实在正确 shell 与目录执行，测试失败是否来自已有基线。
若无法运行检查，交付应写清缺少条件，不要把静态阅读写成已经运行通过。网络中断之后先看工作区状态，再恢复任务，避免重复写入。后续用 AGENTS.md固定 Windows 或 WSL 的项目约定，并按权限说明设置适合的执行边界。
把 Windows 开发约定写成团队文档
如果团队同时有 macOS、Windows 和 Linux 用户，说明哪些命令跨平台，哪些需要特定 shell。不要让新成员通过一次次失败猜项目支持的系统。安装步骤、包管理器、测试前置条件和路径示例要分别标注，避免文档看起来完整却只能在作者电脑上运行。
项目规则中可以明确“Windows 原生使用 PowerShell”“Linux 脚本在 WSL 执行”等已经验证的约定，但不要因为个人偏好禁止其他已经支持的方式。每项结论应对应项目事实；未经测试的平台，写明未验证即可，不要承诺兼容。
代理、证书和网络问题怎么记录
Windows 应用、PowerShell 和 WSL 可能走不同网络配置。浏览器能登录控制台，不证明 CLI 到模型接口的请求成功；终端短请求成功，也不代表长流式连接不会中断。先记录失败阶段、错误类型和所用环境，再决定检查哪一层。
遇到证书错误时，按组织证书和代理政策处理，不要通过关闭证书验证当作长期方案。遇到超时则区分域名解析、连接建立和响应等待。无需把全部网络配置公开，提供脱敏地址、时间和错误信息即可开始排查。
更新之后怎样确认没有退化
先检查版本，再运行一条只读任务、一条受控修改和项目依赖的验证命令。如果你的自动化只使用 CLI，就重点检查那条路径；若日常使用桌面与 IDE，再分别做简短验收。没有新证据时，不必把每个功能都重复跑一遍。
记录升级前后的差异，尤其是配置警告、环境变量继承和权限提示。若确有阻塞，按原安装来源处理版本，而不是同时清空配置、迁移仓库和重装系统。保留可解释的步骤，比碰巧恢复更有利于后续维护。
给第一次使用设一个结束点
当版本、认证、项目路径、只读工具和一次小修改都已确认，就可以结束环境配置，开始处理实际需求。不要为了模仿某篇截图继续安装无关工具。保留这次通过的命令和环境说明，下一次出现问题时先对照它，避免反复从零配置。
官方资料与核对范围
以下资料用于核对产品入口、命令和配置；练习与任务模板是本文提供的操作建议，不代表已在读者设备上运行。官方源码主分支会更新，安装时请再核对本机版本。