你已经在 Cursor 里打开了一个项目。第一次使用 Codex 的目标可以很具体：打开官方扩展、完成认证、把一个边界清楚的小任务交给它，再亲自检查它改了什么。先选一个你熟悉的文件；看得清修改范围、验证结果和恢复路径之后，再逐步扩大任务。
OpenAI 当前将 Cursor 列为 Codex IDE 扩展支持的编辑器。扩展能利用打开的文件或选中的代码提供上下文，并把建议改动放回编辑器供你审阅；安装入口和当前能力应以 Codex IDE 官方文档 为准。界面位置可能随 Cursor 或扩展版本变化，因此下面同时给出图标和命令面板两种入口。
先给第一次任务划清边界
第一次任务最好满足三个条件：代码你能读懂、改动只涉及一个文件、失败后能恢复。不要从生产配置、部署脚本、数据库迁移或带有密钥的文件开始。
先在 Cursor 的终端运行：
bashgit status --short
如果命令列出尚未处理的改动，先决定是提交、暂存还是另开测试分支；不要让已有工作与 Codex 的新改动混在一起。OpenAI 的 IDE 指南也建议在首次任务前后保留 Git 检查点，便于比较和撤销。这里不要求使用某个远程 Git 平台，本地仓库就足以承担第一次验证。
没有使用 Git 的项目也能打开扩展，但你会失去一条清楚的差异与恢复路径。至少先复制待改文件，再把任务限制在这一个文件中。
安装官方扩展并打开 Codex 侧栏
从 Codex IDE 官方文档 进入面向 Cursor 的安装入口，确认安装项由官方链接指向。不要只凭名称或图标相似判断，因为扩展市场里可能存在名称接近的项目。
安装后回到 Cursor：
- 确认扩展已启用；如果刚安装，可以重新加载当前窗口。
- 查看活动栏或侧边栏中是否出现 Codex 图标。
- 如果没看到图标，打开命令面板，输入并执行“Codex: Open Codex Sidebar”。
- 确认 Codex 侧栏能够展开，而不是只看到扩展详情页。
能打开侧栏说明编辑器已经加载扩展，但还不代表账户或项目访问已经准备好。若命令面板里完全没有“Codex: Open Codex Sidebar”，应先检查安装项、启用状态和当前 Cursor 窗口，不必先折腾账户设置。
完成认证，并把“登录成功”与“可用”分开判断
侧栏会引导你使用可用的认证方式。OpenAI 当前的 认证说明 涵盖 ChatGPT 订阅访问和 API key；具体可用能力、工作区限制、配额与费用可能随账户和认证方式变化，应以登录时的产品提示和账户页面为准。
如果你选择 ChatGPT 登录，重点确认登录的是预期账户，并留意组织工作区或管理员策略。如果选择 API key，使用自己控制的 OpenAI API 项目，并在平台侧确认计费和用量限制。不要把 key 粘贴到聊天内容、源码、截图或仓库文件中，也不要使用来源不明的共享密钥。
认证完成后，做两个简单判断：
- 侧栏不再停留在登录提示，并且可以开始新会话；
- 发起请求时没有立即出现账户无权访问、API key 无效或用量受限等提示。
这只能证明认证链路已经工作。Codex 是否拿到了你想提供的代码上下文、是否遵守了文件范围，还要靠下一步的实际任务确认。
用一个小改动完成第一次可审查任务
选择一个行为容易验证的函数，例如输入校验、格式转换或一个小型 UI 状态分支。避免同时打开一堆无关文件；把目标文件放在编辑区，选中要讨论的函数，然后向 Codex 提交一个同时包含目标、范围和验收条件的请求。
例如：
text请检查我选中的 parseConfig 函数。只修改当前文件： 让空字符串输入返回一个带原因的错误结果。 如果测试就在当前文件，请补充对应测试；否则只列出建议测试的用例，不要修改其他文件。 不要改公开 API，也不要安装依赖。先说明准备修改的位置，再给出改动供我审阅。
这里的函数名、返回值和测试要求只是示例，应替换成当前项目的真实约定。一个好的首次请求不需要很长，但应让你能回答四个问题：要实现什么、允许动哪里、哪些行为不能变、怎样算完成。
Codex 回复或生成改动后，先不要直接接受。逐项检查：
- 回答是否提到了选中代码里的真实函数、条件或数据结构，而不是泛泛而谈；
- 修改是否只落在允许的文件和区域；
- 新行为是否符合项目现有的类型、错误处理与测试习惯；
- 是否出现了额外依赖、命令执行、配置更改或大范围格式化；
- 编辑器里的差异是否与它描述的意图一致。
然后在终端再次查看工作区：
bashgit status --short git diff -- path/to/your-file
把示例路径换成实际文件。先读差异，再运行这个项目原有的相关测试或检查命令。只有代码、差异和验证结果都符合预期，才接受或保留修改。若结果不合适，优先使用 Cursor 的变更审阅界面拒绝这次建议；如果准备通过 Git 恢复，也要先确认目标文件没有混入你自己的未提交改动。
怎样判断第一次使用真的成功了
一次完整的首次验证应该留下可以观察的证据，而不是只得到一段看起来合理的回答。
| 环节 | 可观察的成功信号 | 还不能证明什么 |
|---|---|---|
| 扩展加载 | Codex 侧栏能从图标或命令面板打开 | 不代表账户有权限 |
| 认证 | 可以进入会话并正常发起请求 | 不代表项目上下文已参与 |
| 上下文 | 回答准确涉及打开文件或选中代码的具体内容 | 不代表改动一定正确 |
| 修改 | 编辑器显示可逐项审阅的差异，文件范围符合要求 | 不代表测试已经通过 |
| 验证 | 项目原有检查通过，Git 差异与目标一致 | 不代表可以跳过人工审查 |
如果前四项都成立，你已经验证了 Codex 能在当前 Cursor 项目中参与一次受控的代码任务。第五项取决于项目本身的测试与检查机制；项目没有测试时，至少要手动运行相关路径，并明确这次验证覆盖不到哪些情况。
入口、认证或上下文不工作时怎么定位
找不到 Codex 图标或命令
先回到官方 IDE 文档的 Cursor 安装入口，确认扩展已安装，并在你正在操作的 Cursor 窗口中显示为已启用。如果你正在使用 Remote SSH、容器或其他远程环境，就以当前窗口的扩展状态和提示为准，不要拿另一个本地窗口的状态代替。
重新加载窗口后再次搜索完整命令“Codex: Open Codex Sidebar”。命令仍不存在时，优先继续核对安装项、启用状态和当前窗口；侧栏入口尚未出现前，更换登录方式无法验证扩展是否已加载。
侧栏能打开，但认证无法完成
根据你选择的方式检查对应账户。ChatGPT 登录需要确认账户、订阅访问和组织策略；API key 需要确认 key 所属项目、有效状态、用量限制与计费设置。页面出现的具体错误比猜测原因更有价值，记录错误文本和发生步骤，再对照最新官方文档处理。
账户能在浏览器登录，也不一定意味着当前工作区拥有全部 Codex 能力。反过来，认证错误也不能仅凭现象归因为地区或网络。没有可验证证据时，不要用第三方网关、共享账号或来历不明的 key 绕过提示。
能对话，但回答没有使用当前代码
把范围缩到一个打开的文件，并明确选中一段代码；请求中写出“只根据当前选中内容”和目标函数名。不要用“检查整个项目”来做上下文测试，因为范围太大时，很难分辨是上下文未参与，还是任务本身没有清楚边界。
如果缩小后仍然只得到通用回答，新建一个会话再试，并确认焦点仍在目标文件和选区。仍无改善时，查看侧栏当前给出的上下文提示与扩展版本对应的官方说明，不要默认它会自动读取整个仓库。
改动超出要求，或差异无法确认
先拒绝或暂停这次改动，不要通过增加权限来“让它再试一次”。把请求改成单文件、单函数，并明确禁止安装依赖、重命名公开接口或修改配置。必要时让它先解释准备触碰的位置，确认范围后再生成修改。
如果 Codex 请求执行命令，只批准你理解且确实为当前任务所需的操作。涉及删除、覆盖、数据库变更、部署或凭据时，应退出首次验证，改用隔离环境和更严格的审查流程。
从一次成功扩展到日常工作
完成单文件任务后，可以按“一个函数—一个文件—少量相关文件”的节奏逐步扩大范围。每次都保留同样的三道边界：请求中写清允许范围，编辑器里审阅实际差异，项目工具验证结果。任务越大，越需要先建立 Git 检查点，并拆成能单独验收的小步骤。
现在可以回到那个低风险文件，选中一段你熟悉的代码，提交第一个有明确边界的请求。等 Codex 给出修改后，先看编辑器差异，再看 Git 差异；你能解释每一处变化、验证预期行为，并且知道如何撤销，才值得把下一个任务交给它。
