兩次沙箱逃逸真正值得注意的，不只是「AI 又找到漏洞」，而是原本負責限制代理權限的元件，竟可被代理輸入反過來操控。安全研究公司 Accomplish 指出，它在 2026 年 8 月 12 日向 OpenAI 通報 Overpatch 與 Heapjack，兩者均於八天內修補。研究方建議將 Codex CLI 升至 0.149.0 以上、Codex Desktop 升至 26.818.21641 以上。原始揭露見：https://accomplish.ai/blog/escaping-the-openai-codex-sandbox-twice/
事件背景：沙箱與核准流程是兩道不同防線
來源事實：OpenAI 官方文件將沙箱與核准政策定義為相互配合、但彼此不同的控制：沙箱決定程式能接觸哪些檔案與網路資源，核准流程則決定越界時是否必須停下來詢問使用者。依目前文件，read-only 原則上只能檢視檔案；workspace-write 可在工作區內修改檔案；超出邊界的行動應被阻擋或要求核准。文件見：https://learn.chatgpt.com/docs/sandboxing
因此，這兩個漏洞不是單純的介面誤導。Overpatch 讓工作區模式下的寫入越過目錄邊界；Heapjack 更在唯讀模式中通往未受沙箱限制的原生程式，直接破壞使用者對權限模式的核心預期。
Overpatch：一個失敗的補丁項目，替另一個項目放大權限
來源事實：Codex 的 apply_patch 工具必須取得目標檔案所在目錄的寫入權。研究方發現，舊版實作會依補丁內每條路徑的父目錄推導額外權限。攻擊者只要在同一份補丁中加入一個指向 /tmp 的無效變更，系統便可能把其父目錄 / 視為應開放的範圍；補丁中的另一項變更再透過符號連結寫入使用者家目錄下的 .zshrc。即使 /tmp 那項操作本身失敗，擴大的權限仍已被利用。下次使用者開啟終端機時，遭植入的 shell 設定便在沙箱外執行。
這類問題並非只有研究方聲稱存在。2026 年 7 月，OpenAI 的公開 GitHub 專案已有使用者回報 Codex CLI 0.142.5 的補丁工具能在沒有核准提示下修改可寫根目錄以外的 ~/.bashrc；該回報不能證明與 Overpatch 完全同源，卻獨立印證了「shell 被擋、內建補丁工具卻能越界」這一風險類型：https://github.com/openai/codex/issues/31434
OpenAI 公開程式碼目前已先檢查目標是否原本可寫，再推導父目錄權限，並明白註記要避免可寫目錄反向授權其父目錄。這與揭露所描述的修補方向相符：https://github.com/openai/codex/blob/main/codex-rs/core/src/tools/handlers/apply_patch.rs
Heapjack：秘密與不可信程式碼住在同一個記憶體空間
來源事實：研究方描述，受影響的 Codex Desktop 會設定一個 node_repl 工具。未受沙箱限制的 Rust 父程序負責開啟應用程式、連接 Unix socket 與修改全域設定；代理產生的 JavaScript 則在受限制的 Node 程序中執行。問題是，可信與不可信程式碼只是分居同一個 V8 isolate 內的兩個 vm context，而授權父程序操作的隨機 token 也位於同一份 heap。
不可信程式碼可呼叫 v8.getHeapSnapshot() 搜尋形似 UUID 的字串，再利用父程序對錯誤 token 與正確 token 回傳不同錯誤的特性逐一辨識。取得 token 後，它可把仿造的 JSON 請求直接寫入共用的標準輸出管線，由未受沙箱限制的父程序代為執行。研究方的示範透過 macOS 的 open 啟動沙箱外應用程式，並指出同一介面還能連接 Unix socket 或改寫全域 Codex 設定。
Node.js 官方文件提供了關鍵交叉驗證：node:vm 明確「不是安全機制」，不應用來執行不可信程式碼；v8.getHeapSnapshot() 取得的是目前 V8 isolate 的 heap 快照。這支持 Heapjack 所依賴的技術前提，但不是對研究方完整攻擊鏈的獨立重製。文件見：https://nodejs.org/api/vm.html、https://nodejs.org/api/v8.html
共同根因與商業邏輯
合理推論：編碼代理若每次修改檔案、開啟應用程式或呼叫本機服務都要求核准，產品體驗會變得遲鈍；廠商因此會建立高權限輔助程式，替受限代理完成特定操作。這能降低核准疲勞，卻也形成「能力橋接器」：一旦不可信端能影響授權範圍、讀取憑證或偽造通訊，橋接器就會成為 confused deputy，也就是被冒用權限的代理人。
作者觀點：真正的設計原則不是「token 要更難猜」，而是安全決策、真實憑證與高權限執行端，不應與不可信程式碼共享可觀測的記憶體、可偽造的通道或由輸入反推的權限。OpenAI 自己的沙箱安全指引也建議以虛擬機隔離工作負載，並將真實憑證留在環境之外：https://developers.openai.com/api/docs/guides/agents-api/environments/security
影響與容易忽略的限制
風險入口不必是使用者主動執行惡意腳本。編碼代理會閱讀剛複製的 repository、設定檔與任務說明；若其中內容能誘導代理呼叫有缺陷的工具，唯讀模式也不等於可信任該專案。不過，現有資料仍有清楚界線：
- 完整攻擊鏈、修補版本與八天時程主要來自 Accomplish；該公司同時販售以 VM 隔離代理的產品，具有商業利益。
- OpenAI 的 0.149.0 公開發行頁證實該版本於 8 月 20 日發布，但發行說明未明列 Overpatch：https://github.com/openai/codex/releases/tag/rust-v0.149.0
- 目前公開資料未證明漏洞曾遭野外利用，也不足以把 macOS 展示的所有後果直接外推到每一種作業系統與安裝方式。
對台灣開發團隊的意義與後續指標
台灣軟體、IC 設計與供應鏈團隊常在開發機保存原始碼簽署金鑰、雲端憑證、套件 registry token、SSH key 與 Docker socket。這些資產一旦與編碼代理共用同一帳號，沙箱逃逸的價值會遠高於單一專案內容。企業應先盤點並更新 Codex CLI 與 Desktop；把外部 repository 視為不可信輸入；以專用帳號、容器或 VM 執行代理；避免將長效憑證注入代理環境，並限制 Docker socket、家目錄與跨專案寫入。
後續應持續觀察四項指標：OpenAI 是否發布正式安全公告或 CVE、桌面版是否公開 Heapjack 的修補機制、補丁工具的權限推導是否接受跨平台回歸測試，以及終端監控能否偵測代理程序修改 shell 啟動檔、全域 config.toml、連接高權限 Unix socket，或啟動脫離原代理程序樹的應用程式。版本更新是必要動作，但更重要的是把「代理必然會接觸惡意輸入」納入長期架構，而不是再把唯讀模式當作絕對安全的同義詞。