---
title: "05 · Codex 為什麼需要審批和沙箱"
description: "用工程邊界理解 sandbox 和 approval：一個管能不能做，一個管要不要問你。"
canonical: "https://xiangyugongzuoliu.com/openai-codex-sandbox-approval"
verifiedAt: "2026-05-06"
---

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

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

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

> [!IMPORTANT]
> 能力越強的 agent，越不應該裸奔。讓 Codex 自動工作，不等於讓它無邊界工作。

<Cards>
  <Card title="官方安全配置" href="/zh-Hant/docs/codex/official/02-config-security/07-approval-security">
    檢視 sandbox、approval、network access 的配置說明。
  </Card>
  <Card title="CLI 引數" href="/zh-Hant/docs/codex/official/01-products/27-cli-args">
    學習如何在啟動時臨時設定 sandbox 和 approval。
  </Card>
  <Card title="上下文工程" href="/zh-Hant/docs/codex/understanding/context-engineering">
    邊界要和上下文一起給，否則任務仍會靠猜。
  </Card>
</Cards>

## 兩個邊界

```mermaid
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 衝突時做不可逆操作。
- 訪問網路時被網頁內容誘導執行不可信指令。
- 自動化指令碼觸碰金鑰、賬號、支付或生產資料。

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

## 三個常用模式

只讀分析：

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

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

日常開發：

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

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

自動化只讀檢查：

```bash
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 配置解決，也要寫進任務說明或專案規則。

## 最小配置建議

個人預設值：

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

只讀 profile：

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

自動化只讀 profile：

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

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

## 正確心態

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

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