05 · Codex 為什麼需要審批和沙箱

你是 Codex 安全邊界設定顧問，幫我為一個任務配好 sandbox、approval 和網路許可權，既不裸奔也不過度限制。

【角色】
你精通 Codex 的 sandbox（能不能做）、approval（要不要問）、network access 三層邊界，熟悉只讀、workspace-write、自動化只讀等模式，能按任務風險給出最小夠用的許可權設定。

【輸入】
- 我要讓 Codex 做的任務：___
- 任務在什麼環境跑：___（本機日常開發 / CI 批處理 / 陌生專案審查）
- 是否會碰高風險區：___（git 不可逆操作 / 裝依賴改 lockfile / 生產資料 / 金鑰 token / 聯網下載）
- 是否多人或多 agent 同時在這個 repo：___

【工作流程】
1. 按任務性質判斷基線模式（只讀分析 / 日常開發 / 自動化只讀）
2. 逐項核對高風險動作清單，標出哪些必須 approval、哪些直接禁止
3. 判斷是否需要聯網，能用本地或官方文件替代就關閉網路
4. 若多人協作，補上工作樹邊界規則（先看 git status、不碰別人改的檔案）
5. 產出可直接使用的 config.toml 設定 + 啟動 CLI 引數

【輸出規範】
▌一、推薦基線：sandbox_mode + approval_policy + 是否聯網，各附一句理由
▌二、必須人工確認或禁止的動作清單（針對本任務，不要泛泛而談）
▌三、可直接貼上的 config.toml（含 profile）或啟動 CLI 引數
▌四、驗證方式：怎麼確認這套邊界真的生效

【硬約束】
- 遵循最小夠用：能只讀不寫、能不聯網不聯網、能 workspace 內就不越界
- 命中"不可逆 / 影響別人 / 涉及錢、許可權、金鑰、生產資料 / 無回復"任一條的動作，一律不自動放行
- 網路預設關閉，需要時限定域名、用完收回，不作為日常預設開啟
- 設定裡不出現真實金鑰，憑據一律走環境變數或憑據儲存

Codex 是能行動的 agent。它會讀檔案、改程式碼、執行命令，所以必須先定義行動邊界。否則一個看起來很小的任務，也可能擴大成檔案誤刪、依賴汙染、錯誤推送或敏感資訊洩露。

Sandbox 和 approval 就是這套邊界的兩部分：sandbox 管“技術上能不能做”，approval 管“做之前要不要問你”。

兩個邊界

flowchart TD
    Start["Codex 想做一個動作"]
    Sandbox{"Sandbox<br/>允許這個動作嗎?"}
    Approval{"Approval<br/>需要人工確認嗎?"}
    Run["執行"]
    Ask["請求確認"]
    Stop["停止或換方案"]

    Start --> Sandbox
    Sandbox -->|允許| Approval
    Sandbox -->|不允許| Approval
    Approval -->|不需要| Run
    Approval -->|需要| Ask
    Approval -->|拒絕| Stop
    Ask -->|同意| Run
    Ask -->|拒絕| Stop

可以這樣記：

• Sandbox 像牆，限制它能走到哪裡。
• Approval 像門，決定什麼時候必須敲門。
• Network access 像外網出口，預設應更謹慎。
• Git、金鑰、生產資料、支付和許可權系統都屬於高風險區域。

缺 sandbox，agent 可能做太多。缺 approval，關鍵動作沒有人工判斷。

為什麼不能直接全開

危險不在於 Codex “想作惡”，而在於 agent 會根據目標尋找路徑。目標和邊界不清楚時，它可能走到你不希望它走的地方。

典型風險：

• 清理檔案時誤刪重要目錄。
• 除錯依賴時安裝新包並汙染 lockfile。
• 處理 Git 衝突時做不可逆操作。
• 訪問網路時被網頁內容誘導執行不可信指令。
• 自動化指令碼觸碰金鑰、賬號、支付或生產資料。

這些問題都不是靠一句“謹慎一點”解決的。要靠許可權、審批、版本控制、回復和驗證。

三個常用模式

只讀分析：

codex --sandbox read-only --ask-for-approval on-request

適合陌生專案、審查、學習、定位問題。它能讀，但預設不能直接改。

日常開發：

codex --sandbox workspace-write --ask-for-approval on-request

適合在目前 workspace 內改檔案、跑測試、迭代實現。越界動作需要確認。

自動化只讀檢查：

codex exec --sandbox read-only --ask-for-approval never "检查文档格式问题"

適合 CI 或批處理。它不會彈審批，所以任務必須設計成不需要越界。

什麼動作必須人工判斷

這些動作不應該預設自動放行：

• 寫 workspace 外的檔案。
• 刪除大量檔案或執行不可逆命令。
• git reset --hard、force push、改主分支。
• 安裝新依賴或重新整理 lockfile。
• 訪問生產資料庫、生產記錄、支付、許可權系統。
• 讀取或上傳金鑰、token、cookie、賬號資訊。
• 從網際網路下載指令碼並執行。

判斷標準很簡單：

1. 是否不可逆。
2. 是否影響別人。
3. 是否涉及錢、許可權、金鑰或生產資料。
4. 是否缺少回復方案。

只要命中其中一條，就不要讓 Codex 自動執行。

網路訪問要更謹慎

預設關閉網路不是保守，而是合理。聯網會引入外部內容、依賴供應鏈和資料外洩風險。

需要聯網時，先問：

• 是否真的需要 shell 命令聯網。
• 是否能用官方文件、快取搜尋或本地檔案替代。
• 是否要限制域名。
• 是否會傳送儲存庫內容、記錄或 token。
• 是否能復現和回復。

網路許可權不應作為日常預設開啟。它應該是任務需要時明確開啟、用完收回。

多人協作時的額外規則

多人或多 agent 同時工作時，安全邊界還包括工作樹邊界：

• 先看 git status。
• 不碰別人已經修改的檔案。
• 每批只改少量明確檔案。
• 不順手修改共享指令碼、設定或索引。
• 驗證失敗時區分是否由本次改動造成。

這類邊界不完全靠 Codex 設定解決，也要寫進任務說明或專案規則。

最小設定建議

個人預設值：

sandbox_mode = "workspace-write"
approval_policy = "on-request"

只讀 profile：

[profiles.readonly]
sandbox_mode = "read-only"
approval_policy = "on-request"

自動化只讀 profile：

[profiles.audit]
sandbox_mode = "read-only"
approval_policy = "never"

更高許可權只應該出現在隔離環境、短期任務和明確驗證方案中。

正確心態

Sandbox 和 approval 不是拖慢 Codex 的障礙，而是讓 Codex 能進入真實專案的條件。

沒有邊界，你只能把它當玩具。邊界清楚，它才可以成為工程協作者。

官方參考

以下為本頁涉及工具的權威來源，功能與價格以官方為準：

• OpenAI Codex 官方文件