不少人第一次安装 Codex，卡住的地方并不是命令本身，而是命令之后的一连串选择：Windows 还是 WSL2，账号如何登录，模型在哪里配置，项目目录是否有权限，终端能不能执行。
软件装上了，窗口也打开了，但真正能让它进入项目工作的条件还没有凑齐。这也是 Codex 看起来“下载容易、开始困难”的原因。
下面按一条比较稳妥的标准流程，把 Windows 下的安装、登录、模型选择和第一次验证讲清楚。最后再看一下，为什么 MotoAgent 里的 Codex 更适合不想反复折腾环境的人。
一、安装 Codex 前，先把环境准备好
Windows 电脑建议先准备 Git 和 Node.js。Python 不是 Codex 的硬性前置条件，但处理脚本、数据或自动化任务时通常会用到。
可以在 PowerShell 中执行：
winget install --id Git.Git
winget install --id OpenJS.NodeJS.LTS
winget install --id Python.Python.3.14安装完成后关闭当前终端，再打开一个新的 PowerShell，确认命令已经进入系统路径：
git --version
node --version
python --version如果能正常输出版本号，说明基础环境已经就绪。这里最好不要跳过“关闭并重新打开终端”这一步，很多“命令不存在”其实只是旧终端还没有读取新的 PATH。
二、Windows 原生安装：适合先快速跑起来
如果项目主要放在 Windows 文件夹中，或者只是想先体验 Codex，可以直接使用 PowerShell 安装方式：
irm https://chatgpt.com/codex/install.ps1 | iex安装结束后检查版本：
codex --version如果提示找不到 `codex`，先关闭 PowerShell，再重新打开。仍然找不到时，检查安装目录是否已经加入 PATH，或者重新执行安装命令。
Windows 原生方式的优点是路径直观，桌面文件和项目目录比较容易管理。缺点是部分 Linux 工具链、Shell 脚本和开发依赖的行为与服务器环境不完全一致。
三、需要 Linux 工具链时，选择 WSL2
如果日常项目使用 Linux 命令、Shell 脚本或容器工具，WSL2 通常更接近实际开发环境。管理员 PowerShell 中先执行：
wsl --install按提示重启电脑，进入 Linux 终端后安装 Codex：
curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --versionWSL2 下建议把项目放在 Linux 自己的目录，例如：
mkdir -p ~/code
cd ~/code不建议第一次就把整个 Windows 磁盘映射给智能体。项目目录越小，权限边界越清楚，出现误操作时也更容易恢复。
四、登录之后，模型和权限才是关键
安装只是把命令放进系统，登录才是让 Codex 进入可用状态。启动登录流程：
codex login按界面提示选择登录方式。登录完成后，运行：
codex第一次进入对话，不要马上交给它一个大型项目。先使用这些内置命令确认状态：
/status 查看当前登录和工作状态
/model 查看或切换模型
/permissions 查看当前权限
/review 检查当前项目改动不同版本的命令入口可能略有变化，以当前界面显示为准。重点是先确认三件事：当前模型可以回复，当前目录是目标项目，文件和终端权限没有超出预期。
五、第一条任务应该用来验证，而不是用来炫技
进入项目目录后，可以发送一条小而完整的指令：
请先分析当前项目，不要修改文件。
请说明项目入口、主要目录、运行方式和可能的风险。
如果需要执行命令，请先列出命令并等待确认。
最后用三点总结你的判断。这一步能验证 Codex 是否看到了正确的项目，也能观察它是否会在没有授权的情况下主动修改文件。
确认环境没有问题后，再进行一次可回滚的小改动：
请在当前项目中新建 hello.py：
1. 输出当前时间和运行环境；
2. 添加中文注释；
3. 执行一次验证；
4. 如果报错，先说明原因再修复；
5. 最后列出实际修改过的文件。这条指令同时检查了文件创建、终端执行、错误处理和结果汇报。比直接让它重构整个项目，更适合作为第一次验收。
六、为什么很多人装好之后，仍然觉得配置复杂？
问题通常不在某一个按钮，而在几个配置层叠在一起：
| 配置层 | 常见问题 |
|---|---|
| 系统环境 | Git、Node.js 或 Shell 没有进入 PATH |
| 登录认证 | 浏览器登录完成，但终端状态没有刷新 |
| 模型选择 | 模型名称、模型服务和账号权限混在一起 |
| 工作目录 | Codex 没有进入真正的项目目录 |
| 工具权限 | 能回答问题，但不能创建文件或运行测试 |
| Windows 与 WSL2 | 两套环境的路径、依赖和配置并不完全共用 |
所以“安装成功”与“能够稳定工作”是两件事。标准流程的价值，就是把每一层拆开验证，避免在一个错误现象上反复试错。
七、不想反复配环境，MotoAgent 里的 Codex 怎么用？
如果只是想尽快开始体验 Codex，MotoAgent 提供了一个更直观的入口。安装完成后，打开软件，进入 Codex 对话，就可以从模型、会话和项目任务开始使用，不必先在多个终端和配置文件之间来回切换。
上图是启动后的实际 MotoAgent Codex 界面。账户信息已经做模糊处理，保留了对话区、模型信息、权限提示和代码返回区域。它更像一个完整的工作台：左侧管理不同会话，中间处理任务，底部继续输入指令。
一个比较实用的使用顺序是：
- 打开 MotoAgent，进入 Codex 会话；
- 先选择当前可用的模型；
- 指定一个测试项目目录；
- 发送只读分析任务；
- 确认结果后，再允许创建文件或运行测试。
例如可以直接发送：
请检查当前项目的目录结构，先不要修改文件。
用表格说明每个主要目录的作用，并指出最适合从哪里开始阅读。如果只是做代码解释、生成小脚本或整理项目文档，这样的轻量任务已经足够。需要修改代码时，再逐步打开对应权限，使用过程会更稳。
八、两种方式应该怎么选？
| 使用目标 | 更适合的方式 |
|---|---|
| 希望理解 Codex 的底层流程 | Windows 或 WSL2 标准安装 |
| 已经有稳定的开发环境 | 直接使用命令行工作流 |
| 不想单独处理模型和会话配置 | MotoAgent 工作台 |
| 需要多个智能体和模型入口 | MotoAgent 中统一管理 |
| 处理重要项目 | 无论哪种方式，都先备份并限制目录权限 |
MotoAgent 解决的是入口和配置体验，不会替代代码审查。涉及数据库、支付、账号权限和线上部署的改动，仍然需要人工检查、测试和回滚方案。
结语：先把第一条任务跑通，再决定要不要深入配置
Codex 的标准安装并不难，真正容易让人停下来的，是安装、登录、模型、目录和权限被分散在不同层级里。
如果希望理解完整机制，可以按 Windows 或 WSL2 的标准流程逐项验证；如果目标只是尽快开始使用，MotoAgent 里的 Codex 把这些入口集中到一个界面，安装后就能直接进入对话和项目任务。
最稳妥的起点始终是一条只读分析指令。先确认它看到了什么、准备做什么，再让它修改文件。这样既能快速上手，也能保留对项目的控制感。
