Back to Details

codex-bug

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Codex Bug

Codex Bug

Overview

概述

Diagnose a Codex GitHub bug report and decide the next action: verify against sources, request more info, or explain why it is not a bug.
诊断Codex的GitHub bug报告并决定后续操作：针对源代码验证问题、请求更多信息或解释为何不是bug。

Workflow

工作流程

  1. Confirm the input
  • Require a GitHub issue URL that points to 
    github.com/openai/codex/issues/…
    .
  • If the URL is missing or not in the right repo, ask the user for the correct link.
  1. Network access
  • Always access the issue over the network immediately, even if you think access is blocked or unavailable.
  • Prefer the GitHub API over HTML pages because the HTML is noisy:
    • Issue: 
      https://api.github.com/repos/openai/codex/issues/<number>
    • Comments: 
      https://api.github.com/repos/openai/codex/issues/<number>/comments
  • If the environment requires explicit approval, request it on demand via the tool and continue without additional user prompting.
  • Only if the network attempt fails after requesting approval, explain what you can do offline (e.g., draft a response template) and ask how to proceed.
  1. Read the issue
  • Use the GitHub API responses (issue + comments) as the source of truth rather than scraping the HTML issue page.
  • Extract: title, body, repro steps, expected vs actual, environment, logs, and any attachments.
  • Note whether the report already includes logs or session details.
  • If the report includes a thread ID, mention it in the summary and use it to look up the logs and session details if you have access to them.
  1. Summarize the bug before investigating
  • Before inspecting code, docs, or logs in depth, write a short summary of the report in your own words.
  • Include the reported behavior, expected behavior, repro steps, environment, and what evidence is already attached or missing.
  1. Decide the course of action
  • Verify with sources when the report is specific and likely reproducible. Inspect relevant Codex files (or mention the files to inspect if access is unavailable).
  • Request more information when the report is vague, missing repro steps, or lacks logs/environment.
  • Explain not a bug when the report contradicts current behavior or documented constraints (cite the evidence from the issue and any local sources you checked).
  1. Respond
  • Provide a concise report of your findings and next steps.
  1. 确认输入
  • 需要指向
    github.com/openai/codex/issues/…
    的GitHub issue链接。
  • 如果链接缺失或不属于正确的仓库，请向用户索要正确链接。
  1. 网络访问
  • 立即通过网络访问该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
  • 如果环境需要明确的访问权限，请通过工具按需申请，并无需额外用户提示即可继续操作。
  • 仅当申请权限后网络访问仍失败时，说明你可离线完成的操作（例如，草拟回复模板），并询问后续处理方式。
  1. 阅读issue内容
  • 以GitHub API的响应内容（issue + 评论）为真实数据源，而非抓取HTML格式的issue页面。
  • 提取以下信息：标题、正文、复现步骤、预期结果与实际结果、环境信息、日志以及任何附件。
  • 记录报告中是否已包含日志或会话详情。
  • 如果报告中包含线程ID，请在总结中提及，并在有权限的情况下使用该ID查找对应的日志和会话详情。
  1. 调查前先总结bug信息
  • 在深入检查代码、文档或日志之前，用自己的语言撰写一份简短的报告总结。
  • 总结内容需包含报告的问题现象、预期行为、复现步骤、环境信息，以及已附证据或缺失的信息。
  1. 决定行动方案
  • 针对源代码验证：当报告内容具体且大概率可复现时，检查相关的Codex文件（若无法访问则提及需检查的文件）。
  • 请求更多信息：当报告内容模糊、缺少复现步骤或无日志/环境信息时。
  • 解释为何不是bug：当报告内容与当前行为或文档中说明的约束条件相矛盾时（引用issue中的证据及你检查过的本地数据源）。
  1. 回复
  • 提供简洁的调查结果和后续步骤说明。