用途：诊断 openai/codex 的 GitHub bug 报告，并决定后续动作——对照来源验证、请求更多信息，或解释为何不算 bug。
主要能力与流程：
- 确认输入：需要一个指向 github.com/openai/codex/issues/… 的 issue URL；若缺失或仓库不符，向用户索取正确链接。
- 网络访问：立即通过网络访问该 issue，即使认为访问被阻断也要尝试。优先使用 GitHub API 而非 HTML 页面，因为 HTML 噪声较大： Issue：https://api.github.com/repos/openai/codex/issues/<number> Comments：https://api.github.com/repos/openai/codex/issues/<number>/comments 若环境需要显式批准，按需通过工具请求批准并继续，无需额外提示用户。只有在请求批准后网络仍失败时，才说明离线可做的事（如起草回复模板）并询问如何继续。
- 阅读 issue：以 API 返回的 issue 与评论为准，而非抓取 HTML。提取标题、正文、复现步骤、预期与实际、环境、日志及附件，并记录是否已包含日志或会话详情。若报告含 thread ID，在摘要中提及，并在有权限时用它查询日志与会话详情。
- 调查前先总结：用自己的话写简短摘要，包含报告行为、预期行为、复现步骤、环境，以及已有或缺失的证据。
- 决定行动：报告具体且可能可复现时，对照来源验证，检查相关 Codex 文件（无权限时说明应检查哪些文件）；报告含糊、缺复现步骤或缺日志/环境时，请求更多信息；报告与当前行为或文档约束矛盾时，说明不是 bug，并引用 issue 与本地来源的证据。
- 回复：给出简明的发现与下一步报告。
适用场景：收到 openai/codex 的 GitHub issue 链接并需判断后续处理时。
限制：资料未提供该技能的安装方式、收费、平台支持或效果数据；其行为依赖对 GitHub API 的网络访问与相应权限。