OpenAI 詳解 Windows 版 Codex 沙箱設計：用合成 SID 告別頻繁彈窗

讓一個 AI 幫你在電腦上寫程式碼，就像把鍵盤借給一個剛認識的實習生。在 Mac 和 Linux 上，系統自帶現成的防盜鎖；但在 Windows 上，很長一段時間裡你只有兩個極端選擇：要麼每讀一個檔案都要你點確認，要麼直接把大門完全開啟，讓它在你的硬盤裡隨意折騰。

OpenAI 工程師 David Wiesen 披露了他們為 Windows 版 Codex 打造原生沙箱的完整技術內幕。David 在 2025 年 9 月加入 Codex 團隊時發現，Windows 上的 Codex 根本沒有沙箱環境，使用者只能在煩瑣的頻繁彈窗與徹底放任自流的危險之間二選一。

微軟自家方案為何全軍覆沒

要在本地安全執行程式碼智慧體，關鍵是控制兩件事：不準亂改工作區之外的檔案，不準未經允許悄悄往外網發資料。macOS 依靠 Seatbelt，Linux 依靠 seccomp 或 bubblewrap 就能輕鬆做到，但 Windows 系統開箱並不提供這類通用的輕量隔離工具。

OpenAI 團隊首先調研了微軟自帶的三種隔離方案，結果全部落選。

第一個被排除的是 AppContainer。它是 Windows 原生的應用沙箱，但要求程式預先明確知道要訪問什麼。然而 Codex 驅動的是任意 shell、Git、Python 直譯器和編譯工具，這類開放式的開發者工作流根本無法被裝進這麼死板的容器裡。

第二個是 Windows Sandbox 輕量虛擬機器。它雖然隔離徹底，但它每次啟動都是個乾淨的獨立虛擬桌面，開發者真實的專案環境、工具鏈都在宿主機上，打通兩者極其麻煩。更致命的是，Windows 家庭版系統壓根就沒有這個功能。

第三個是微軟的強制完整性控制（MIC）。OpenAI 曾嘗試讓 Codex 以低完整性執行，並把專案目錄標記為低完整性。但這意味著宿主機上的任何低完整性惡意程序都能隨意寫入開發者的程式碼倉庫，反而把使用者的實際工作區變成了全系統的安全洩洪口。

既不要管理員許可權，又要鎖死讀寫與網路

為了不要求使用者每次都以管理員許可權啟動，David Wiesen 帶著團隊用 Windows 底層的安全積木搭了一套屬於自己的無提權沙箱。

在控制檔案寫入方面，他們組合了合成安全識別符號（Synthetic SID）與寫入受限令牌（Write-restricted token）。在 Windows 底層，寫入受限令牌在執行寫入操作時會進行雙重核查：既要求當前使用者有許可權，又要求令牌限制列表中的某個 SID 也具備許可權。

利用這一特性，Codex 生成了一個名為 sandbox-write 的虛擬身份，只對當前工作目錄和配置檔案裡指定的額外根目錄賦予寫和執行許可權。與此同時，它對目錄內的 .git、.codex 和 .agents 等關鍵資料夾顯式拒絕寫入，確保 AI 絕不可能擅自改動版本庫本身。

在控制網路訪問上，因為沒有管理員許可權無法呼叫 Windows 防火牆，團隊在首個原型中採取了阻斷常見通道的思路。他們將環境變數中的代理地址全部指向死埠 127.0.0.1:9，讓 Git 的 HTTP 請求直接撞牆，把 Git SSH 命令替換為直接退出的指令碼，並在環境變數最前端插入打樁命令攔截 SSH。

不過團隊也承認，這種毒化環境變數的做法雖然能攔住絕大多數標準命令列工具，但屬於建議性質的軟攔截，如果底層程序強行直接開啟網路套接字，理論上依然有逃逸的風險。

為什麼重要

對於每天在 Windows 上寫程式碼的開發者來說，這項改進的價值是立竿見影的。此前使用本地 AI 智慧體，你要麼忍受無休止的手動確認彈窗，要麼在關閉防護後時刻提心吊膽，生怕程式碼執行弄壞整個系統。自研沙箱終於讓 Windows 開發者獲得了與 Mac 和 Linux 平起平坐的安全體驗。

從行業角度看，智慧體落地最大的阻礙正在從模型智商轉向客戶端許可權治理。模型生成程式碼越來越快，但把它下放到真實作業系統中執行時，作業系統的傳統許可權模型已經遠遠落後於需求。Windows 缺乏類似 Linux namespace 的開箱即用隔離原語，迫使上層應用廠商不得不自行下潛到底層去組裝補丁方案。

我們認為，OpenAI 堅持不依賴管理員許可權的做法非常聰明，這保住了極佳的開箱即用體驗。但在網路層面的軟攔截暴露出 Windows 客戶端沙箱依然存在隱患。未來如果 Windows 官方不出面提供系統級的擴音權隔離 API，這類智慧體客戶端的安全博弈恐怕還會繼續消耗開發者的大量精力。