---
title: "設定審批和安全邊界"
description: "理解 Codex 的 sandbox、approval、network access 和自動審批審查，給本地與雲端任務設定正確邊界。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

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

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

> [!WARNING]
> 不要為了省確認步驟，把 `danger-full-access` 或 `--yolo` 設為日常預設。越是自動化場景，越需要外層隔離、可回復和最小許可權。

<Cards>
  <Card title="Agent approvals & security" href="https://developers.openai.com/codex/agent-approvals-security">
    檢視 sandbox、approval、network access 和安全建議的官方說明。
  </Card>
  <Card title="Sandboxing concepts" href="https://developers.openai.com/codex/concepts/sandboxing">
    理解本地和雲端 Codex 的 sandbox 行為。
  </Card>
  <Card title="Configuration Reference" href="https://developers.openai.com/codex/config-reference">
    查詢 `config.toml` 中相關配置項的型別和預設行為。
  </Card>
</Cards>

## 兩層控制

```mermaid
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`：取消沙箱限制，只適合外層已經隔離的受控環境。

推薦預設：

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

只讀審查：

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

指令碼化只讀檢查：

```bash
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` 預設不應隨意開啟網路。確實需要時，顯式配置並說明原因：

```toml
[sandbox_workspace_write]
network_access = true
```

更穩的做法：

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

## 自動審批審查

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

典型配置思路：

```toml
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`：

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

為常用模式設定 profiles：

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

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

啟動時選擇：

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

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

## 安全檢查清單

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

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

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