codex-bug

Codex Bug

概述

诊断 Codex GitHub Bug 报告，并决定下一步操作：根据来源验证、请求更多信息，或解释为什么这不是 Bug。

工作流

1. 确认输入

• 要求提供指向 github.com/openai/codex/issues/… 的 GitHub Issue URL。
• 如果缺少 URL，或 URL 指向的仓库不正确，请向用户索要正确的链接。

2. 网络访问

• 立即通过网络访问 Issue，即使你认为访问受阻或不可用，也要尝试。
• 优先使用 GitHub API，而不是 HTML 页面，因为 HTML 内容杂乱：
  • Issue：https://api.github.com/repos/openai/codex/issues/<number>
  • 评论：https://api.github.com/repos/openai/codex/issues/<number>/comments
• 如果环境要求明确批准，请按需通过工具请求批准，然后继续操作，无需再次询问用户。
• 只有在请求批准后网络尝试仍失败时，才说明你可以离线完成的工作（例如，起草回复模板），并询问下一步如何处理。

3. 阅读 Issue

• 以 GitHub API 响应（Issue + 评论）为准，而不是抓取 HTML Issue 页面。
• 提取：标题、正文、复现步骤、预期与实际结果、环境、日志和任何附件。
• 说明报告是否已包含日志或会话详情。
• 如果报告包含 thread ID，请在摘要中提及，并在你有权限时用它查找日志和会话详情。

4. 调查前总结 Bug

• 深入检查代码、文档或日志之前，先用自己的话简短总结报告。
• 包括所报告的行为、预期行为、复现步骤、环境，以及已附带或缺失的证据。

5. 决定处理方式

• 根据来源验证：当报告具体且可能可复现时。检查相关 Codex 文件（如果无法访问，则说明需要检查哪些文件）。
• 请求更多信息：当报告描述模糊、缺少复现步骤，或缺少日志/环境信息时。
• 解释这不是 Bug：当报告与当前行为或文档中的限制相矛盾时（引用 Issue 中的证据以及你检查过的任何本地来源）。

6. 回复

• 简洁地报告调查结果和后续步骤。