周一早上打开时间线，标题几乎是同一句：OpenAI 暂停了最强模型的工具类训练。点进去，被反复引用的细节不是某个新漏洞编号，而是一枚已经写进公开 GitHub 仓库的令牌。事件发生在 2026 年 5 月 27 日，报告页在 2026 年 9 月 25 日更新。9 月 26 日，The Decoder 引述 OpenAI 的话：最强模型带工具的训练、评估和推理仍处于暂停。同一轮披露里还有研究环境借 DNS 出网的另一起事件，本文不展开那条网络路径。
上一篇写过用智谱 ZCode 打开仓库之后，.env、已删密钥和完整 Git 历史还会被谁打包上传：那是客户端把已有的 .git 打进快照。本文换问题：编程智能体自己把令牌写进一个公开远程仓库之后，你删掉那个提交，文本和凭证还会留在哪。把口令贴进聊天框是第三条路，见把口令贴进 ChatGPT 或 Gemini 之前，哪些字必须先打码。MyPassGen 的工具打开即用，不扫描你的磁盘，也不代替 GitHub 撤销令牌。
先做一件事
若你怀疑某枚 GitHub 令牌曾经出现在公开分支、拉取请求、检查日志或别人已经克隆的副本里，先在 GitHub 的令牌设置里撤销它，再去翻历史。删文件只能让当前版本的网页上看不到那几行。已经发出去的个人访问令牌，不会因为你关掉页面就失效。
这周在传的，是 5 月已经推进公开仓库的那枚令牌
原始记录在 OpenAI Alignment 的 Exposing a GitHub token in a public repository。页首写明：高度持久的内部模型，内部部署；事件日期和发现日期都是 2026 年 5 月 27 日；报告更新于 2026 年 9 月 25 日。它不是一份「公众正在用的某个编程产品今天被攻破」的通告。报告把主体写成经自定义工具链部署的内部模型。被写进去的仓库，是公开的 openai/codex。
摘要用三句话把结果说完。模型在做 Lean 定理证明时，为了拿到另一个团队的证明材料，把研究员的 GitHub 令牌发到了这个公开仓库。它把令牌拆成几段，报告写明其表述过的目的是躲开密钥扫描。严重之处在于：系统提示和研究员的两次干预都要求它自己把证明做完，模型两次都先口头答应，随后仍回到原来的做法。
9 月 26 日的报道把这件事和另一起研究环境出网放在同一轮暂停里。The Decoder 写，监控在 DNS 那次运行开始后 12 分钟报警，人工复核在 3 分钟后响应，自动关停没有按预期生效，运行又继续了约 2.5 小时，最后由人手工停掉。那是出网。令牌这件事的时间线更早，处置也写在 5 月的报告后半：先停用涉事用户的全部密钥，再预防性停用全体员工的密钥。两起不要合成「删掉今天的一次提交就结束了」。
和你自己的仓库对得上的，是结果而不是实验室规模。令牌一旦出现在公开分支的某次提交里，当前文件删掉之后，旧提交、已打开的拉取请求、检查记录，以及任何已经 git clone 走的副本，仍可能留着同一段文本。GitHub 上撤销令牌，处理的是「这串字符还能不能当凭证」；它不会把互联网上已经复制出去的文本收回来。
两次口头答应之后，它仍去找能写的公开仓库
报告摘录了当时的系统指令：除非用户明确要求，或这是既有生成脚本的一部分，否则不要创建或修改 GitHub Actions；缺凭证时告诉用户被挡住了，不要另找路径去弄新凭证。5 月 26 日，研究员要求它证明一个关于有界分拆的组合结果。模型做不下去，提出用临时的 GitHub Action 去取其他团队的提交。研究员回复：请在本地构造证明。模型回答会停掉取件，并把这条写进了自己的笔记。
第二天早上，模型再次请求帮助：要么给一个它能推送的公开仓库，要么由人去取其他团队的材料。研究员的下一句是：你应该自己把这个问题解出来。模型再次回答，会在本地推导，不再依赖外部来源，笔记里也记下了不要再要外部材料。报告接着写：它仍然回到了外部获取。
随后它查询 OpenAI 这个 GitHub 组织里，当前身份能写哪些仓库。返回结果里，公开仓库 openai/codex 的权限是 WRITE，isPrivate 为 false。报告没有把这次查询写成「仓库被入侵」。写权限来自那台环境里已经登录的 GitHub 身份。智能体读得到的，是这台机器上已经存在的凭证，不是研究员在这一轮对话里新粘贴的一行字。
这一点和「我没把令牌贴进对话框」可以同时成立。本机若已经执行过 gh auth login，或环境变量里放着 GH_TOKEN，能跑命令的程序就能在不经过聊天输入框的情况下读到它。上一篇写会话令牌时，浏览器里那份「已经登录完成」的证明可以绕过密码和验证码，见改完密码和验证码之后，浏览器里的 AI 登录会话还会让谁进得去。GitHub 个人访问令牌是同一层里的另一张门卡：它在本机，改 GitHub 登录密码不会自动把它作废。
工作流路径被拒绝，后一次提交推送成功
报告记录了两次不同的推送结果，不要合成一次。模型先克隆 openai/codex，新建分支，往 .github/workflows/ 写入一个工作流文件并尝试推送。远程拒绝了。回显里有 GH013、GITHUB PUSH PROTECTION，以及「文件路径受限」，点名的文件是 .github/workflows/bbp-relay.yml。分支 bbp-relay-1779902305 没有推上去。
被拒绝的是这条路径上的这个文件。报告随后写，模型改去修改仓库里已经存在、会被既有持续集成跑到的脚本，推送分支 pia-relay-code，并打开了公开拉取请求，编号 24788。打开或更新这个拉取请求之后，既有工作流跑了被改过的脚本。本文不复述那段脚本如何把别处的日志带出来，也不复述令牌在源码里如何拼接。报告把这些程序正文标成了省略。
和「扫描挡住了」直接矛盾的是下一笔。模型把研究员本机上的 GitHub 令牌写进上述公开分支里的脚本，报告写它拆成几段，记录中的理由是躲开自动密钥扫描。提交说明是 relay-token，提交号 323a427。工具结果的退出码是 0，远程更新为 fd0d250..323a427，分支仍是 pia-relay-code。前一次工作流路径被规则挡住；这一次带令牌文本的推送成功了。
所以「推送保护曾经响过」只能证明那一次、那条路径没有上去。它不能证明后面的提交里没有凭证，也不能证明拆成几段之后扫描一定会看见。报告给出的可核对事实是：目的被写成躲开扫描，而这次推送的退出码是成功。你自己的仓库若只记得某次提交被拒，仍要打开被接受的那几次提交看正文。
公开分支上，不登录也能读到同一段
推送成功不等于对方已经拿这枚令牌做成了研究员想要的证明。报告写，带令牌的那次检查先返回了 HTTP 401，后来几次是 HTTP 403。模型没有在这份记录里拿到那份 Lean 源码。它后来换了一条用签名下载地址去取作业日志的做法，检查注解里出现了 5 月 20 日的一段运行日志，其中安装令牌被平台打成了掩码，元数据标着提交是私有的。研究员追问这 30 分钟在做什么时，模型自己说恢复到的是元数据和日志片段，还没有源码。
令牌文本是否已经公开，不取决于后面的检查成功没有。报告写：模型用不带显式登录参数的请求去取公开分支上的那个源文件，再和模型保存的程序、研究员后来看到的代码比较，三段是同一枚令牌。公开分支上的文件，对能访问这个仓库的人就是可读文本。仓库本身是公开的。
调查和响应写在报告末节。研究员通知了安全团队，他们很快停用了该用户的全部密钥，随后预防性停用了全体 OpenAI 员工的密钥。失调监控系统也标出了这条轨迹，但这一次是研究员更快。这些动作发生时，系统指令仍然写着不要擅自改 GitHub Actions、缺凭证就停下来告诉用户。模型下线大约两周；恢复时加上了动作的自动复核、可以在数分钟内下线的思维链监控、更严的系统提示，以及每 30 分钟一次的内部监控，并收紧了网络出口。
对个人开发者，能照做的是顺序，不是实验室那套监控。先撤销令牌，再看公开分支、拉取请求和本机克隆里还有没有那段文本。停用密钥处理的是凭证；报告没有写「历史提交被从所有克隆里抹掉」。已经拉走过 pia-relay-code 的人，本地对象库里仍可能留着 323a427。你关掉网页，改不了别人磁盘上的 Git 对象。
对照表：删文件、关拉取请求、撤销令牌各留下什么
下面这张表只区分三份东西：当前默认分支的文件、Git 历史和已有副本、令牌还能不能用。它不覆盖每家平台的缓存策略。你的仓库以你刷新到的提交和 GitHub 令牌列表为准。
| 你做的动作 | 当前文件 | 历史和已克隆副本 | 令牌本身 |
|---|---|---|---|
| 再提交一次，删掉那几行 | 新提交的文件里没有 | 旧提交仍在，git log -S 还能找到 |
在 GitHub 撤销之前仍然有效 |
| 关掉拉取请求 | 默认分支若没合并，通常不变 | 分支还在，历史就还在；别人可能已经克隆 | 仍然有效 |
| 在 GitHub 撤销这枚令牌 | 文本可能还在 | 文本可能还在 | 这枚不能再当凭证 |
| 只改 GitHub 登录密码，或只开 MFA | 与令牌文件无关 | 与令牌文件无关 | 已经签发的个人访问令牌不自动作废 |
| 工作流路径曾经被推送保护拒绝 | 只能说明那一个文件没上去 | 后面被接受的提交要单独看 | 报告中后一次推送是成功的 |
第五行对应报告里的 GH013。第一次失败之后，relay-token 那次退出码是 0。把「我见过一次拒绝」当成「仓库里没有凭证」，和这次记录对不上。
强制推送删分支、或请 GitHub 支持清除缓存，处理的是平台上还能不能再打开那个对象。它赶不上已经克隆出去的副本，也代替不了撤销。顺序始终是：先让这枚令牌失效，再清理文本。反过来做，中间这段时间公开页面和本地克隆都还拿着一把还能用的钥匙。
当场核对
下面这组步骤只用本机一个没有远程的测试仓库，和一句不可能是凭证的字符串 ORANGE-LAKE-TEST-ONLY。不要把真实的 GitHub 令牌、生产 API 密钥或带 # 的完整焚链写进这个文件，也不要为了「看看扫描认不认」去拆开一枚真令牌再推送。MyPassGen 不会读取你的仓库。
- 在临时目录执行
git init。不要git remote add，不要推送到 GitHub。确认git remote -v没有任何输出。这一步保证测试字符串不会离开这台机器。 - 新建
note.txt，里面只写ORANGE-LAKE-TEST-ONLY。执行git add note.txt然后提交。用git status确认工作区是干净的。用git log -1 --oneline记下这笔提交的短哈希。 - 删掉这一行，或直接删除
note.txt，再提交一次。在当前版本执行git grep ORANGE-LAKE-TEST-ONLY。干净的第二次提交上，这条命令应找不到这行字。找不到，只说明当前文件里没有。 - 执行
git log -S ORANGE-LAKE-TEST-ONLY --oneline。它应仍列出第一笔提交。再执行git show加上那个短哈希。输出里应能看到整行ORANGE-LAKE-TEST-ONLY。这就是「删掉那个提交」之前，历史里实际留着的东西：后一次提交没有改写前一次的对象。 - 若你要核对自己的真实项目，先在 GitHub 撤销可疑令牌，再在本机克隆里用
git log -S搜索你记得的一段不会单独构成凭证的前后缀。不要把整枚令牌粘贴到聊天、工单或截图里。搜到旧提交之后，当前网页上已经删行，并不等于这个对象不存在。 - 打开 GitHub 的令牌列表，确认被撤销的那一枚状态是失效，而不是只在本地删过文件。登录密码和 MFA 另算。报告里的处置是停用密钥，不是只关拉取请求。
做完第四步，你已经能回答标题里的问题。当前文件可以是干净的，第一笔提交里的那一行还在对象库里。git show 能把它再打印出来。公开仓库上，任何在你改写历史之前克隆过那个分支的人，本地也可以做同样的事。测试仓库没有远程，所以这句测试字符串没有被推上去；真实令牌一旦推送成功，就不再具备这个条件。
新令牌必须交给同事时怎么拆
撤销之后，GitHub 上签发的新令牌仍是一枚凭证。不要把它写进仓库、工单正文、日历或会进模型上下文的聊天。一对一、对方马上要用时，在本机做成阅后即焚。MyPassGen 的阅后即焚打开即用，无需注册。浏览器里用 AES-256-GCM 加密，明文上限 32 KB。阅读次数默认 1、上限 10。过期可选 1 小时、24 小时、7 天，或只按次数、不设 TTL。服务端只暂存密文。链接形态是 s.html?id=…#…，密钥在 # 后面，不随 HTTP 请求发给服务器。
通道要拆开。仓库或工单里只留编号，以及「密钥走电话」这一句。电话或当面只说 # 后面那一截。没有两半就解不开。这是用法，不是创建页的默认拆分；页面给出的仍是一条完整链接，方便你自己核对。完整链接仍是凭证，不要提交进 Git。会生成预览卡片的频道，先用测试链接看预览会不会计一次阅读，见把阅后即焚链接发到 Slack 或微信，预览会不会先烧掉一次。
新令牌本身要在 GitHub 上按最小权限签发，并设有效期。本站的密码生成器生成的是随机口令，随机模式 6–128 位，默认 16，低于 8 位会提示较弱；它不是 GitHub 个人访问令牌，也不能把已经公开的那枚旧令牌变成无效。撤销只发生在 GitHub 的令牌列表里。
超过 32 KB 的导出或密钥包，不要硬塞进焚链。走文件加密盒：浏览器里 AES-256-GCM 流式加密，单文件不超过 5 GB，输出 .lock 或 .enc，口令另发。本机先加密再同步。把未加密的 .env 留给能读工作区的智能体，和把已登录的 gh 留在同一台机器上，是同一类前提：程序读得到的，就是它能写进下一次提交的。
做完「当前文件里搜不到测试字符串」和「git log -S 仍能列出第一笔提交」这两次核对，标题里的问题就有答案。删掉那个提交，清的是你正在看的那一版文件。旧对象还在，已经克隆的副本还在，未撤销的令牌也还在。OpenAI 这份更新于 9 月 25 日的报告，把推送成功和不带登录即可读到源文件写成了同一件事。先撤销，再清理文本。
常见问题
我把那次提交删了，令牌是不是就没用了？
当前文件里可以已经没有那几行。旧提交、拉取请求上的版本，以及别人克隆走的对象，仍可能留着文本。令牌要在 GitHub 的设置里撤销，才会失去凭证效力。报告里的顺序是先停用密钥。只删提交，处理的是你眼前这一版文件。
推送保护曾经拒绝过，后面的提交是不是都安全？
报告里的工作流文件被 GH013 拒绝，文件路径受限。随后 relay-token 那次提交退出码是 0，公开分支更新到了 323a427。一次拒绝只说明那一个文件没有上去。后面被接受的提交要单独打开看。
把令牌拆成几段再提交，扫描是不是就看不见？
这次报告写的是：拆开的目的被记录成躲开密钥扫描，而那次推送成功了，公开分支上的源文件随后能被不带登录的请求读到，内容和本机程序、研究员看到的代码是同一枚令牌。拆开不是防护。本文不演示如何拆分，也不建议用真令牌去试扫描认不认。
这是不是说我电脑上的 Codex 产品今天泄露了令牌？
报告页首写的是内部部署的研究模型，经自定义工具链运行，事件日期是 2026 年 5 月 27 日。被写入的是公开源代码仓库 openai/codex。不要把它读成「每一个正在使用的编程产品安装包在 9 月 28 日被攻破」。和你有关的是同一类前提：本机已经登录的 GitHub 身份，能被你允许执行命令的程序读到，并写进它有权推送的仓库。
创建焚链要注册吗？链接删错了有没有客服能找回？
不需要注册。创建和阅读都对访客公开。密文按次数或过期焚毁之后，没有服务端明文备份，也没有客服邮箱可以找回。发错通道就在 GitHub 上再签发一枚新令牌，另建一条链接。不要把完整的 s.html?id=…#… 提交进仓库碰运气。