設定審批和安全邊界

Codex 能讀程式碼、改檔案、執行命令，所以安全邊界必須先於自動化。核心控制有兩層：sandbox 決定技術上能做什麼，approval 決定什麼時候必須停下來問你。

本頁是配置和安全參考，不是完整欄位表。具體 key、預設值和平臺差異以官方文件為準。

兩層控制

flowchart TB
    Action["Codex 想執行動作"]
    Sandbox{"Sandbox 是否允許?"}
    Approval{"Approval policy 是否要求確認?"}
    Run["執行"]
    Ask["請求使用者審批"]
    Block["拒絕或暫停"]

    Action --> Sandbox
    Sandbox -->|允許| Approval
    Sandbox -->|不允許| Approval
    Approval -->|不需要確認| Run
    Approval -->|需要確認| Ask
    Approval -->|策略拒絕| Block
    Ask -->|批准| Run
    Ask -->|拒絕| Block

Sandbox 和 approval 不是替代關係：

• Sandbox 是技術邊界，限制檔案、網路、系統命令等能力。
• Approval 是決策邊界，決定某些動作是否需要人工確認。
• Network access 是額外高風險維度，預設應保持收緊。
• Cloud environment 還有 setup 階段、agent 階段、secrets 生命週期等邊界。

常見 sandbox 模式

日常理解三檔就夠：

• read-only：適合只讀分析、陌生專案、學習和審查。
• workspace-write：適合日常開發，允許在當前 workspace 內修改。
• danger-full-access：取消沙箱限制，只適合外層已經隔離的受控環境。

推薦預設：

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

只讀審查：

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

指令碼化只讀檢查：

codex exec --sandbox read-only --ask-for-approval never "检查项目风险"

不要把危險模式當作“效率模式”。它減少的是提示，增加的是事故半徑。

Approval policy 怎麼選

常見策略：

• on-request：日常推薦。沙箱內動作自動執行，越界或敏感動作請求確認。
• never：不彈審批。適合 CI 或自動化，但必須接受越界動作會被拒絕。
• untrusted：更謹慎，適合完全陌生專案或高風險目錄。
• granular policy：適合團隊或企業精細控制不同審批類別。

選擇方式：

• 本地開發：優先 workspace-write + on-request。
• 只讀審計：優先 read-only + on-request。
• 自動化檢查：優先 read-only + never。
• 受控批處理：先外層隔離，再考慮更高許可權。

網路訪問要單獨判斷

網路訪問不是普通許可權。它可能帶來 prompt injection、資料外洩、依賴供應鏈和不可復現問題。

本地 workspace-write 預設不應隨意開啟網路。確實需要時，顯式配置並說明原因：

[sandbox_workspace_write]
network_access = true

更穩的做法：

• 能用官方文件或快取搜尋解決，就不要給 shell 命令完整聯網能力。
• 需要安裝依賴時，先確認 lockfile、registry、版本和回復方式。
• 需要訪問內部系統時，用最小許可權 token，並避免寫入公開日誌。
• Cloud environment 中的 secrets 只放必要內容，並確認它們在哪個階段可用。

自動審批審查

Codex 支援把某些審批請求交給 reviewer agent 先審查，再決定是否允許繼續。這適合團隊希望降低人工審批噪音，但又不想完全放開的場景。

典型配置思路：

approval_policy = "on-request"
approvals_reviewer = "auto_review"

使用前要理解：

• 它只審查本來需要審批的動作。
• 它會帶來額外模型呼叫。
• 它不是安全責任轉移，最終策略仍由團隊負責。
• 高風險、破壞性、資料外洩相關動作仍應保持人工審查。

企業環境可以透過 managed configuration 統一 reviewer policy。

本地與雲端的差異

本地 CLI、IDE、App：

• 主要依賴作業系統級 sandbox。
• 工作目錄、可寫 root、額外目錄由本地配置決定。
• 網路訪問和 shell 命令風險更接近你的真實機器。

Cloud / Web：

• 執行在 OpenAI 託管的 cloud environment。
• 適合非同步任務和儲存庫級工作。
• environment setup、internet access、secrets、GitHub 許可權需要單獨治理。
• 不能把本機許可權模型直接套到雲端。

所以同一個任務，入口不同，安全評估也不同。

配置落地

個人預設值可以寫進 CODEX_HOME/config.toml：

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

為常用模式設定 profiles：

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

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

啟動時選擇：

codex --profile readonly
codex exec --profile automation-readonly "列出潜在风险"

專案規則、團隊限制和共享策略應放在專案或 managed configuration 中，不要散落在個人 prompt 裡。

安全檢查清單

啟用或調整許可權前，確認這些問題：

1. 當前目錄是否受版本控制管理。
2. 是否存在其他人或其他 agent 的未提交改動。
3. 是否需要訪問 workspace 外檔案。
4. 是否真的需要網路訪問。
5. 是否會觸碰金鑰、支付、許可權、生產資料或部署系統。
6. 是否有測試、構建、dry-run 或回復方式。
7. 是否能解釋為什麼當前許可權組合是必要的。

Codex 的安全配置不是為了阻止它工作，而是讓它在可審查、可回復、可證明的範圍內工作。