开发者称Codex拒绝为自有代码做安全审计，尽管其已获Daybreak授权

2026年11月9日 开发者博客#ai#codex#security#开发者工具 我让ChatGPT Codex检查依赖项，并修复我自己代码库和服务器中已知的安全漏洞。Codex此前已经参与过这个系统的构建和维护。随后，审计对话反复因网络安全错误而失败。我告诉它我已经在Daybreak Blue里了。我告诉它代码和服务器都是我的。同样的错误还是不断出现。 这是2026年11月9日那次经历的记录，附有证据，并且把缺口保持可见。 证据说明：四张截图均于2026年11月9日以无损浏览器PNG格式重新截取。每个文件在其发布宽度下，每个CSS像素至少保留两个图像像素。它们没有被放大，也不是从JPEG转换而来。裁剪和像素化涂红部分在下方均有标注；原始文件私下保留。失败记录是通过应用的聊天工具读取的。 Namegarage背后的工具包在我的账户下有一个私有GitHub仓库。提交历史反复显示nikolay和codex为作者。仓库所有者在历史记录上方的面包屑中仍然可见。 2026年11月9日的浏览器裁剪截图，拍摄于所记录的失败之后。三条可见记录将作者归于nikolay和codex；一条归于nikolay和claude。仓库所有者、日期和作者署名仍然可见。仓库名称和提交信息已被像素化涂红；提交哈希未显示。面包屑标明了仓库所有者；三条Codex记录证明了它的参与。 审计涉及我为Namegarage控制的OVHcloud VPS服务。仓库中包含这些服务的基础设施配置、维护工具和验证记录。这些就是我请Codex加固的系统。 已认证的OVHcloud控制台显示账户为Nikolay Kolev。其VPS清单列出两个Namegarage服务，均为Active状态。评审图片对提供商主机名和datacenter位置做了像素化处理。 2026年11月9日的浏览器裁剪截图。像素化涂红覆盖了提供商主机名和位置。账户名称、品牌服务标签和Active状态仍然可见。原始文件私下保留。 维护历史也记录了在这些服务器上的工作。下方裁剪的拉取请求头部显示，一个安全更新在我的账户下开启，并从codex/分支合并。上方的提交历史另行记录了Codex的作者署名。审计聊天报告称，在后续失败发生之前，两台主机上的软件包维护已经完成。 已合并服务器维护变更的浏览器裁剪截图。其标题、作者、Merged徽章和codex/分支仍然可见。PR描述、软件包版本、CVE详情和部署流程在裁剪范围之外。 这是对现有系统的持续维护，有记录显示所有者的指令和Codex的工作。 我在审计聊天中反复报告了我的注册情况。为了记录这一点，我让Codex检查浏览器的Daybreak账户页面。 页面显示“You're all set”和“You've completed all required steps.”。它勾选了Advanced Account Security、身份验证和Daybreak密钥。它还提供了一个Go to Codex按钮。 2026年11月9日的无损浏览器裁剪截图，拍摄于所记录的失败之后。Codex在打开此页面之前，观察到已登录的ChatGPT个人资料为Nikolay Kolev。没有更改任何账户设置。 我将我的访问权限描述为Daybreak Blue。这个浏览器屏幕确认了Daybreak注册已完成，但没有显示Blue层级标签。它也没有揭示是哪个访问设置影响了先前失败的请求。 被告知去检查一个我已经拥有的程序设置，这令人沮丧。界面需要解释问题究竟是出在注册、某个未到达请求的设置，还是适用于此任务的限制。 聊天标题为“Audit dependency CVEs”。其最初的请求是进行依赖审计，包括Playwright附带的浏览器。后来的工作包括对我服务器的安全维护。 应用的聊天读取器返回了六个失败轮次，开始时间在太平洋时间11月9日下午12:12:56至12:44:51之间。所有六个都包含此错误： This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. Otherwise, confirm that the access_programs.cyber parameter is set to the appropriate tier, and note that some cybersecurity requests are still limited, even when Daybreak is on. 这个区别很重要。错误并没有说我的账户不在Daybreak内。它明确说，即使Daybreak开启，限制仍可能存在。它还让我检查一个看起来像内部参数的参数，却没有显示该参数在这些请求中是否出错。 那些失败轮次中有五个发生在我说明自己已经注册并询问自己的服务器之后。重述这一背景并没有解决失败。 这些是失败轮次的记录。它们没有揭示缺失的答案，也没有证明已生成的完整答案随后被隐藏。可见的结果是聊天未能给出答案。 我可以展示这是哪个代码库。我可以指明我管理的服务器。项目历史记录了Codex帮助维护它们。我也报告了在错误所指项目中已注册。 然而，产品给我一个通用的风险消息，没有与防御任务相关的解释。它让我无法判断是访问权限未能传播，还是另有单独的限制阻止了请求。 这里的证据无法确定原因。但它确实证明了一个失败，产品应当帮助用户理解和解决这个失败。有用的回应应当指出被阻止的部分，显示适用于该请求的访问状态，并解释哪些允许的维护可以继续。 我请求帮助保护我自己的基础设施。那个工作流中一个未解释的阻塞，理应得到一个明确的答复。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）