Codex GitHub 审查不触发、@codex review 没反应？逐步排查与验证

在 GitHub 的 pull request（PR）里评论了 @codex review，却没看到反应；或者手动请求能出结果，自动审查一直不来。先把两个问题分开：这次请求是否有可见的处理记录，以及审查是否已经完成、只是没有行内意见。 没评论不等于没运行，出现 👀 反应也不等于审查已经完成。

这篇处理 GitHub 集成中的 Codex Code Review，也就是常说的 codex review not triggered。如果你是在本地聊天中审查工作区，先看 Codex 代码审查工作流；如果失败发生在 GitHub Actions 的任务日志，转到下文的“确认入口”，不要混用修复方法。

先按现象找下一步

当前看到什么	能确认什么	先做什么
评论后没有 👀，也无结果	尚未确认请求被处理	核对仓库与准确触发文本
已有 👀，但无最终结果	Codex 对请求作出了反应	查后续记录、错误及对应结果
没有行内意见	还不能判断成功或失败	找明确的审查结果与覆盖范围
手动正常，自动不运行	手动链路曾可用	查仓库、个人偏好及事件
明确提示权限或额度错误	已有具体失败线索	按提示处理对应条件

没有足够证据时，状态就记为“尚未确认”，不强行归到“没触发”。记录 PR、评论链接、提交版本和时间，后面每次只改一个条件，才知道哪一步起了作用。

1. 确认你用的是 GitHub 审查入口

适用情况： 不确定评论、CLI、应用里的审查和 CI 是否属于同一套功能。

对照你实际操作的位置：

GitHub PR 评论中的 @codex review：本文的手动代码审查入口。
Codex 设置中的自动审查：不依赖每次手动评论，但要满足仓库、个人设置与触发事件条件。
本地 CLI、IDE 或应用中的审查：本地审查能成功，不足以证明 GitHub 已连接或自动审查已启用。
GitHub Actions 中的 openai/codex-action：它在 workflow 里运行 codex exec，应检查该次 Actions 的事件、job 和日志。可继续看 exec 输出与异常退出排查及官方 Action 文档。

普通 @codex 修复请求与 @codex review 也不同。官方 GitHub 文档将其他任务导向 legacy cloud chat；不能拿“修复任务能启动”当作 Code Review 已开启的证据。Security Review 另有专用入口和设置，也不等于普通代码审查。

验证： 你能明确指出失败的是哪一个入口，并找到它对应的评论、设置或 Actions run。若是 CI job 没执行，就沿 workflow 排查，不先调整个人自动审查开关。

2. 核对 PR 所属仓库与审查开关

适用情况： 手动请求无反应、仓库列表找不到目标，或从未成功运行过 GitHub 审查。

先看 PR 页面所属的 owner/repository，再打开 Codex code review 设置。不要只凭本地目录名或同名仓库判断；来自 fork 的 PR 也要核对 PR 页面所属仓库，而不是只看来源分支所在的 fork。

依次检查：

当前 Codex 登录身份及工作区是否是你准备使用的身份，GitHub 连接是否对应正确账号或组织。
目标仓库是否确实已连接到 Codex，设置列表里能否选到准确的 owner/repository。
进入目标仓库设置，确认代码审查已启用；按当前官方界面，相关开关位于 Review code → Automatic review。

预期结果： 设置里的目标与原 PR 一致，并能确认该仓库的审查状态。若仓库缺失或设置不可修改，先让有权管理该仓库连接的人员核查已授权范围与组织限制；不要为排查一个仓库就默认开放全部私有仓库，或反复断开所有连接。

官方明确规定，配置自动审查需要对应仓库的 push 或 admin 权限。这是配置条件，不应扩写成“所有手动请求都必须拥有管理员权限”。无权改设置时，应由有权限的人处理目标项；不能靠在本机提权、切换 CLI 沙箱或添加 API Key 绕过。

两项容易误判的前提也要排除：

AGENTS.md 用于补充仓库审查规则，不是启动审查的必需文件。没有它，不应直接判定触发失败；规则内容另见 AGENTS.md 指南。
当前自动 cloud review 文档说明，无需创建或管理云端环境。不要为了评论审查不运行，先新建旧版 Codex Cloud 环境。

失败后： 仓库或开关仍无法确认，就停在这一层收集权限信息；只有前置条件明确后，下一次触发测试才有解释价值。

3. 用准确评论验证手动触发

适用情况： 已确认目标仓库连接和代码审查状态，需要区分评论入口问题与自动触发问题。

回到原 PR，在普通 PR 评论框提交以下纯文本；这是 GitHub 评论，不是终端命令：

@codex review

按官方推荐入口做一次清晰、可追溯的请求，不用 issue、标签或“请求人工 reviewer”代替这条 PR 评论。记录评论链接、提交时间和当时的 PR 最新提交；测试时尽量先保持该提交不变，避免后续 push 让结果对应哪个版本变得不清楚。

预期结果： 官方流程是 Codex 对评论作出 👀 反应，随后发布审查。观察时分开记录“已反应”和“已出现最终结果”：

没有 👀 也没有结果：只能说尚未确认已处理。重新检查第 1、2 步及评论实际文本，不能据此证明请求从未进入后台。
有 👀，没有结果：已有可见响应，但尚未证明完成；查看该评论之后的记录、关联的 Codex 结果或明确错误，再进入第 5 步。
出现审查结果：核对它属于这次 PR 和预期变更，再判断是否有发现，而不是只数行内评论。

本文不给“等满两分钟就失败”之类固定时限，也不把某个 emoji 单独当作所有版本的完成契约。不要连续刷相同评论；先检查已有请求，修正已确认的问题后再做一次有记录的验证。

验证： 同一 PR 上能找到本次请求及对应审查结果，才算手动链路验证完成。只发出了评论、只看到反应，仍属于中间状态。若设置已经修正而仍无结果，保留记录，继续查明确的权限、额度或服务错误。

4. 手动正常，自动审查却没触发

适用情况： 同一目标仓库里已有成功手动审查记录，但你希望 PR 活动能自动触发。

打开同一份 code review 设置，分别检查以下三层，不能只看见一个开关亮了就结束：

仓库层：在准确的目标仓库中，检查 Review code → Automatic review。
个人层：检查 Personal preferences → Automatic review。当前官方说明，这一项用于你的 PR；同事开启了个人偏好，不等于你的 PR 也已经启用。
事件层：检查 Review trigger，把页面实际选中的条件与这次 PR 活动对照。不要自行假定每次 push、重新打开、转为 ready 都会触发。

先记录原值，再只修正与目标不符的选项。仓库级设置影响团队使用，应由有权限的人按团队约定修改；只想排查一次手动请求时，无需顺带改变全仓库的自动策略。

预期结果： 三层设置与目标一致。接着使用团队允许的测试 PR，在保存设置后产生一个确实符合当前 Review trigger 的事件，记录事件时间、PR 版本及随后结果。不要为了制造事件而向生产分支推无关改动。

验证： 这次没有新增手动 @codex review 评论，符合条件的事件之后仍出现对应审查结果，才能确认自动链路；手动成功只验证手动链路。不要把改开关前的旧事件当作一定会补跑的任务。

如果再次手动能成功，而匹配事件后仍无法确认自动结果，求助时提供三层设置和事件时间，继续按“自动链路未确认”排查，不必重复修改本地 config.toml。如果手动也开始失败，就回到仓库、身份及明确错误检查。

5. 没有行内评论：查结果、范围与明确错误

适用情况： 已有响应，但不知道审查是否完成；或者没有找到预想中的意见。

先在 PR 中查看后续时间线、review 记录及相关评论。有自动 cloud review 时，也可到 Codex 的 Code Review 查看对应 PR；官方资料说明自动审查意见可出现在 GitHub 和该入口。它与在 PR 聊天中另外启动的审查不同，不要把别的任务结果当成本次结果。

按证据处理，而不是猜测：

明确已完成，没有高优先级发现：当前 GitHub Code Review 聚焦 P0、P1 问题，不保证每次都有行内评论。查看结果描述的范围与限制；没有发现不等于代码绝无缺陷，合并前仍需项目测试和团队审查。
找到了结果，但对应较早提交或其他任务：只能说明那一次有结果。对照 PR 变更和结果上下文，最新修改是否已审查仍需单独确认。
明确权限、仓库不可访问或组织限制错误：先核对当前身份和目标仓库的已授权范围；需要管理员介入时，给出目标仓库和脱敏错误，不请求无关权限。
明确额度或 usage limit 错误：查看当前账号或工作区可见的 Code Review 用量、提示的限制和可用时的重置时间。以实际提示为准，不预设所有账号有相同次数或每周同一时刻恢复。
明确任务失败或服务错误：保留错误与发生时间，按界面提供的重试、状态或支持入口处理；若没有错误也没有结果，仍记“未确认完成”，不编造根因。

官方用量说明将 GitHub 中的手动及自动审查计入 Code Review 用量，本地或其他入口的审查按通用用量处理。因此“CLI 还可用”不能单独排除 GitHub 审查额度问题；同样，没有明确额度提示也不能反推一定是配额耗尽。无需为验证这件事盲目购买额度或反复请求审查。

6. 怎样确认问题已经解决

先确认自己要恢复的是手动还是自动审查，再对照证据：

验证目标	完成依据	还不足以说明成功
手动请求	请求能对应到可查看的审查结果	评论已发出、只有 👀
自动触发	匹配事件后出现对应结果	仅手动请求成功
审查范围	结果与目标 PR、预期变更相符	只有旧提交的结果
修复缺陷	复查修改并通过相关项目检查	仅仅没有新的行内意见

若本次只有配置和文档核对，没有实际运行审查，就如实记录“尚未验证触发成功”。不要把一个未知状态写成完成，也不要为了制造“成功”而故意在真实项目中加入漏洞。

仍失败时，给出一份能接着查的记录

向仓库维护者或产品支持提供：

入口：手动 PR 评论、自动审查，还是 GitHub Action。
目标 PR、相关评论链接、时间与时区、对应提交；私有仓库信息只在有权访问的支持渠道分享。
仓库审查开关、个人偏好与 Review trigger 的相关状态，以及本次实际发生的事件。
是否有 👀、是否找到审查结果、是否有明确错误，以及结果对应的变更范围。
已尝试的单项调整和结果；截图遮去无关私有仓库、账号信息和敏感代码，不附 token、Cookie 或完整认证配置。

这样可以说明“卡在哪一步、还有什么没确认”，比只有一句“Codex 没反应”更容易继续定位。若审查已经正常，只是反馈不符合项目需要，再看代码审查范围与可执行反馈；若仓库规则被忽略，再查 AGENTS.md 读取与执行偏差，不要把它们都归为触发问题。

本文于 2026-10-17 重新核对 OpenAI 官方 GitHub 集成、自动 cloud review、用量与 GitHub Action 文档。步骤依据当前官方流程；未在用户真实 PR 上触发审查、修改仓库授权或故意制造故障，不把文档核验表述为所有账号的故障复现。