週一早上打開時間軸，標題幾乎是同一句：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。會產生預覽卡片的頻道，先用測試連結看預覽會不會先計一次閱讀。台灣常用的 LINE 也用同一套核對，見把閱後即焚連結貼到 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=…#… 提交進儲存庫碰運氣。