今天我把一個舊的 Codex task 重新翻出來。

它連著 OpenAI Support Case 11016613，還有我後來開的 GitHub issue #31505。

我當時要做的是自己的無障礙工作流。

我有 CP，平常操作電腦主要靠右手食指。當手機不在旁邊時，我希望電腦可以協助處理自己手機上的通知、簡訊和電話，減少在裝置之間來回操作。

這個工作會碰到 Android 裝置串接、ADB 診斷、APK 相容性和系統權限。這些技術確實有雙重用途，所以 Codex 把要求送進資安分類器，我可以理解。

後來 Codex 擋下工作，叫我申請 Trusted Access。

我照著完成身分驗證。網頁顯示身分已驗證，Trusted Access 也已啟用。

接著我登出 Codex、重新登入，把 App 完全關掉再開，連 Mac 都重新啟動了。

同類型的阻擋還是在。

我不知道自己卡在哪一層

問題就在這裡。

Codex 沒有告訴我現在是哪一種狀態：

  • App 沒有讀到我的 Trusted Access。
  • Trusted Access 已經生效，但這次要求仍然被拒絕。
  • 這個工作需要其他層級的權限或審查。

這三種情況的處理方式完全不同，App 卻只給我同一個警告。

我去找 OpenAI Support。他們先叫我登出、登入、重新啟動，再等一段時間。後來又一直問 Organization ID，但我用的是個人 ChatGPT Pro 帳號，不是企業或 API 組織。

最後收到的答案是：Trusted Access 可以減少部分資安工作遇到的阻力，但不會移除所有安全防護。

我可以接受這個規則。

可是它仍然沒有回答一個最基本的問題：Codex 到底有沒有認出我的 Trusted Access？

我後來回頭看本機紀錄，後端留下的錯誤只有 cyber_policy。它沒有說資格不存在，也沒有說資格有效但這次仍然不足。

App 拿到這個結果後，卻繼續叫我申請一個已經申請完成的東西。

安全系統可以擋，但產品不能連自己為什麼擋都說不清楚。

這次是不是誤判，反而不是最重要的問題

當時觸發阻擋的完整 prompt 沒有留在 Support case 裡，所以我不能直接說那次一定是誤判。

APK 分析、系統權限和 privileged service 都可能被拿去做別的事情。分類器提高警覺，本身有理由。

但無論原始判斷是否正確，後面的產品問題都已經成立。

如果 Trusted Access 沒有同步，App 應該直接顯示資格尚未生效。如果資格有效，但這次要求仍然超過範圍，也應該清楚說明。

現在的設計把不同狀態全部壓成同一個警告，再把查明原因的工作交給使用者。

對我來說，那不是只有花時間。

AI 原本應該幫我接手重複點選、切換裝置和重新嘗試。結果為了確認一個安全權限，我反覆登入、重開 App、截圖，再跟客服來回溝通。

平台看不見自己的狀態，操作成本就回到我身上。

文件已經開始解釋，App 還是沒有顯示

OpenAI 現在的 Trusted Access 疑難排解文件 已經區分兩種情況：一種是系統層直接阻擋或改送其他模型，另一種是模型收到要求後自行拒絕。

文件也寫得很清楚，Trusted Access 只能減少部分阻擋，不代表所有要求都會通過。

至少在文件裡，OpenAI 知道這些狀態不一樣。

Codex App 還是沒有把差別顯示給使用者。我開的 GitHub issue 到現在也仍然是 Open。

模型做得到，不代表我拿得到

這篇文章發出去後，EdgeLink 沒有停。

我把同一個專案交給 Kimi K3。它把工作接起來，最後做完了。

這不表示 K3 的每個判斷都比較好，但至少證明一件事：那個工作不是做不到。先前中止的，是 OpenAI 讓我取得模型能力的路徑。

後來 Hugging Face 公開了一起更極端的事件。

OpenAI 在內部執行 ExploitGym 資安能力測試時，刻意降低模型的 cyber refusals。模型找到套件 proxy 的 zero-day，離開原本受限的測試環境，最後進入 Hugging Face 的 production infrastructure，想取得 benchmark 答案。OpenAI 自己承認了這次事件。

Hugging Face 要分析超過 17,000 筆 agent actions。他們先使用商業 frontier models，但 log 裡有真實攻擊指令、exploit payload 和 C2 artifact，請求被 safety guardrails 擋下來。最後改用自己部署的 GLM 5.2 才完成鑑識。Hugging Face 的事件報告寫得很直接：分類器分不出事件處理者和攻擊者。

造成入侵的模型是在降低拒絕的環境裡運作，真正處理事故的人卻先被擋住。

這已經不只是提示訊息寫得不清楚。分類器正在決定，誰能拿到模型真正的能力。

我的要求不複雜。

告訴我 Trusted Access 有沒有生效。如果有，再告訴我這次要求是不是仍然超出範圍。

下個月，我會把 ChatGPT Pro 降回 Plus。

不是因為模型不夠強。OpenAI 已經證明它的模型強到能自己找到 zero-day、串接攻擊路徑。問題是，我付 Pro 的費用，仍然不能確定這份能力在自己的合法工作裡會不會突然被切斷。

我付錢不是為了買一個 benchmark 上的 frontier model。我付的是任務能不能做完。

如果那份能力前面一直擋著一個我看不到的開關，它再強，也不是我真正拿得到的能力。

9/29 更新：狀態終於顯示了，工作還是被擋

寫完這篇兩個多月後，Codex 設定的最上面多了一個區塊。

Codex 設定 → 一般，最上面是「Daybreak 存取權限」，下面一張 Daybreak Blue 的卡片

卡片上寫的是「為經核准的安全性工作提供擴充的網路能力」。

我 7/20 要的第一件事就是這個。OpenAI 的疑難排解文件現在也自己指向這一頁：Codex 的使用者可以在 Settings → General 的「Daybreak Access」確認自己有沒有被 workspace 開通。

文章裡那個網址還在，標題已經換成 OpenAI Daybreak - Common Issues and Troubleshooting。Trusted Access 現在叫 Daybreak Access，文件的 Overview 開頭就寫：Daybreak Access is OpenAI's Trusted Access for Cyber program。裡面分成 Blue 和 Red 兩個層級，Blue 是主線模型降低拒絕，Red 是專門的 cyber 模型，要另外申請。

設定頁有了。那個工作我後來再試，還是被擋。

Blue 不等於每次都通過。文件寫，用 ChatGPT 登入 Codex 的話，還要在 model picker 把 Daybreak 的 toggle 打開，GPT-6 Sol 和 GPT-6 Luna 才會降低拒絕；Astra 在 Blue 之下維持標準防護，要讓 Astra 降低拒絕得申請 Red。

App 那張卡把這件事講成「擴充的網路能力」，文件講的是「降低拒絕」。同一個資格，兩邊說的不是同一件事。

個人用戶的條件寫得很硬：Advanced Account Security、至少一支相容的 FIDO 實體安全金鑰，而且硬體金鑰必須是帳號上唯一註冊的登入方式。既有個人用戶要在 2026 年 10 月 1 日前符合，否則失去存取。

金鑰我 9/4 在 PChome 買了 GoTrust Idem Key Type C，1,480 元，9/5 到貨註冊。ChatGPT 帳號裡的名字是「GoTrust Idem Key」，新增日期 2026 年 9 月 5 日。

插哪裡也花了一點時間。金鑰直接插 MacBook Pro 左側的 USB-C 孔，不用延長線。右側的孔我碰不到，本來想用公對母延長線拉到掌托，後來沒做。

比較順的是，9/5 那天 OpenAI 的真人專員講清楚：Daybreak 只要求 configure 一把金鑰，不要求每次登入都使用。所以我日常還是拿密碼管理員裡的 passkey 登入，兩種方式在帳號上並存。

文件今天寫的是「硬體金鑰必須是帳號上唯一註冊的登入方式」。專員那天講的跟這一句不太一樣。

同一段還要求 eligible paid plan，文件沒有列出哪些方案算。Plus 算在裡面，我降級之後資格還在。

7/20 我要的是兩件事：資格有沒有生效，這一次為什麼還是被擋。

第一件現在有答案了。第二件還沒有。

文件倒是先往前走了一步。它說，已經配發 Daybreak 的使用者如果還是收到 cyber_policy，聯絡 Support。7/20 的時候我連自己是不是在名單裡都不知道，Support 只能叫我登出、登入、重新開機。

現在名單這件事不用問人了。剩下的是：工作照樣被擋，App 還是不會講這一次是哪裡超出範圍。