智能體審批與安全

Codex 會盡量保護你的程式碼和資料，並降低誤用風險。

預設情況下，智能體會在關閉網路存取的狀態下執行。在本機，Codex 會使用由作業系統強制執行的沙箱限制它可以接觸的內容範圍，通常只限於當前工作區；同時還會配合審批策略，控制它在執行操作前何時必須暫停並向你請求確認。

如果你想先了解 ChatGPT 桌面版、Codex CLI 和 IDE 擴充套件中的沙箱機制，請參見沙箱機制。如果你需要更廣泛的企業安全概覽，請參見 Codex 安全白皮書。

沙箱與審批

Codex 的安全控制由兩層共同配合實現：

• 沙箱模式：決定 Codex 在技術上能做什麼，例如可以寫入哪些位置、是否能夠存取網路。這個限制會在執行模型生成的命令時生效。
• 審批策略：決定 Codex 何時必須先請求你的核准，例如離開沙箱、使用網路，或執行不在受信任集合內的命令。

Codex 會根據執行位置採用不同的沙箱模式：

• Codex 雲端：執行在 OpenAI 管理的隔離容器中，無法存取你的宿主系統或無關資料。它使用兩階段執行時模型：setup 階段先於智能體階段執行，可以存取網路以安裝指定依賴；隨後智能體階段預設離線執行，除非你為該環境顯式開啟網際網路存取。為雲端環境設定的金鑰只在 setup 階段可用，並會在智能體階段開始前移除。
• Codex CLI / IDE 擴充套件：由作業系統級機制強制執行沙箱策略。預設包括關閉網路存取，並且把寫權限限制在當前活動工作區內。你可以根據自己的風險承受範圍設定沙箱、審批策略和網路設定。

在 Auto 預設下，例如 --sandbox workspace-write --ask-for-approval on-request，Codex 可以自動讀取檔案、編輯檔案，並在工作目錄中執行命令。

如果 Codex 需要編輯工作區之外的檔案，或者執行需要網路存取的命令，它就會請求審批。如果你只想聊天、規劃或閱讀程式碼而不做修改，可以通過 /permissions 切換到 read-only 模式。

即使操作不是 shell 命令或檔案修改，Codex 也可能為帶副作用提示的應用（連接器）工具呼叫請求審批。只要某個應用 / MCP 工具聲明瞭 destructive 註解，就一定需要審批，即便它同時還聲明瞭其他較弱的提示，例如只讀提示。

網路存取（高風險）

對於 Codex 雲端，請參見智能體網際網路存取，瞭解如何開啟完整網際網路存取或設定域名允許列表。

對於 ChatGPT 桌面版、Codex CLI 或 IDE 擴充套件，預設的 workspace-write 沙箱模式會保持網路關閉，除非你在設定中顯式啟用：

[sandbox_workspace_write]
network_access = true

網路隔離

網路存取由目的地規則控制，這些規則會作用於命令派生出來的指令碼、程式和子程序。當命令網路存取已經開啟時，可以開啟 network_proxy 功能，把這些流量約束在你設定的網路策略內。

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

對於一次性的 CLI 會話，如果只需要切換開關，可以使用布林簡寫；如果還要設定策略選項，則使用 table 形式：

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

codex \
  -c 'features.network_proxy.enabled=true' \
  -c 'features.network_proxy.domains={ "api.openai.com" = "allow", "example.com" = "deny" }' \
  -c 'sandbox_workspace_write.network_access=true'

這個功能會改變已啟用網路存取的強制執行方式；它本身不會授予網路存取。是否允許命令聯網，仍由 workspace-write 設定中的 sandbox_workspace_write.network_access 決定：

• 網路關閉 + network_proxy 開啟：網路仍然關閉，這個功能不會產生效果。
• 網路開啟 + network_proxy 關閉：網路保持開啟，並允許不受限制的直接出站存取。
• 網路開啟 + network_proxy 開啟：網路保持開啟，出站流量會受設定的網路策略約束。

管理員託管的 experimental_network 要求與使用者側功能開關相互獨立。它們可以在不設定 features.network_proxy 的情況下設定並啟動沙箱化網路，但如果當前啟用的沙箱本身關閉了網路存取，它們不會開啟網路。管理員側 requirements.toml 的結構見託管設定。

網路策略

域名規則採用允許列表優先的行為：

• 精確主機只匹配它自己。
• *.example.com 匹配 api.example.com 這樣的子域名，但不匹配 example.com。
• **.example.com 同時匹配根域名和子域名。
• 全域 * 的 allow 規則會匹配任何未被 deny 的公共主機。應把 * 視作寬泛網路存取，優先使用範圍更窄的規則。
• deny 始終優先於 allow，且全域 * 只能用於 allow 規則。

本機和私有目的地

預設情況下，allow_local_binding = false 會阻止 loopback（迴環）、link-local（鏈路本機）和私有目的地：

• 特定例外：當命令只需要存取某個本機目標時，新增精確的本機 IP 地址字面量或 localhost 的 allow 規則。
• 更寬的存取：只有當你明確想允許更寬的本機 / 私有網路存取時，才設定 allow_local_binding = true。
• 萬用字元：萬用字元規則不算作顯式本機例外。
• 解析後地址：解析到本機或私有 IP 的主機名仍會被阻止，即便它匹配允許列表。

DNS rebinding 保護

在允許某個主機名前，Codex 會盡力執行 DNS 和 IP 分類檢查：

• 查詢失敗或超時會被阻止。
• 解析到非公共地址的主機名會被阻止。
• 這項檢查會降低 DNS rebinding 風險，但不能完全消除風險。要徹底防止 rebinding，需要在 transport 層固定解析出的 IP。

如果你的威脅模型包含惡意 DNS，也應在更低層實施出站控制。

危險設定

有兩個設定會刻意擴大信任邊界：

• dangerously_allow_non_loopback_proxy = true 可能把代理監聽器暴露到迴環地址之外。
• dangerously_allow_all_unix_sockets = true 會繞過 Unix socket 允許列表。

只能在嚴格受控的環境中使用它們。啟用 Unix socket 代理時，即使請求了非迴環繫結，監聽器仍會只繫結迴環地址，因此沙箱網路不會變成通往本機守護程序的遠端橋接。

network_proxy 預設關閉。啟用後：

你也可以在不為派生命令授予完整網路權限的前提下，單獨控制 Web 搜尋工具。Codex 預設通過 Web 搜尋快取存取結果。這個快取是 OpenAI 維護的網頁結果索引，因此 cached 模式返回的是預先索引好的結果，而不是即時抓取頁面。這樣能降低暴露於任意即時內容提示詞注入的風險，但你仍應把 Web 結果視為不可信輸入。

如果你使用 --yolo 或其他完全存取沙箱設定，Web 搜尋會預設切換為即時結果。你可以使用 --search 或設定 web_search = "live" 來允許即時瀏覽，也可以把它設為 "disabled" 關閉該工具：

web_search = "cached"  # default
# web_search = "disabled"
# web_search = "live"  # same as --search

如果外部 Web 存取必須經過搜尋索引，請設定 web_search = "indexed"。無論是啟用網路存取還是啟用 Web 搜尋，都需要格外謹慎；提示詞注入可能會誘導智能體獲取並遵循不可信指令。

預設值與建議

• 啟動時，Codex 會檢測當前資料夾是否受版本控制，並據此給出建議：
  • 受版本控制的資料夾：Auto（workspace-write + on-request 審批）
  • 不受版本控制的資料夾：read-only
• 取決於你的設定，Codex 也可能在你顯式信任當前工作目錄之前先以 read-only 啟動，例如通過首次引導提示或 /permissions 完成信任。
• 工作區不僅包括當前目錄，也包括 /tmp 之類的臨時目錄。你可以通過 /status 檢視哪些目錄屬於當前工作區。
• 如果你要接受預設行為，直接執行 codex 即可。
• 你也可以顯式指定：
  • codex --sandbox workspace-write --ask-for-approval on-request
  • codex --sandbox read-only --ask-for-approval on-request

可寫根目錄中的受保護路徑

在預設的 workspace-write 沙箱策略下，即使某個根目錄可寫，其中仍然包含受保護路徑：

• 無論 <writable_root>/.git 是目錄還是檔案，都會被作為只讀保護。
• 如果 <writable_root>/.git 是一個指標檔案（gitdir: ...），其解析後的 Git 目錄路徑也會被作為只讀保護。
• 當 <writable_root>/.agents 存在且為目錄時，會被作為只讀保護。
• 當 <writable_root>/.codex 存在且為目錄時，會被作為只讀保護。
• 保護是遞迴的，因此這些路徑下的所有內容都會保持只讀。

在不彈出審批提示的情況下執行

你可以通過 --ask-for-approval never 或簡寫 -a never 關閉審批提示。

這個選項適用於所有 --sandbox 模式，因此你仍然可以控制 Codex 的自主性邊界。Codex 會在你設定的限制內盡最大努力完成任務。

如果你需要 Codex 在沒有審批提示的情況下讀取檔案、編輯檔案並執行帶網路存取的命令，可以使用 --sandbox danger-full-access，或等價的 --dangerously-bypass-approvals-and-sandbox 標誌。啟用前請務必謹慎。

如果你希望採用中間方案，可以使用 approval_policy = { granular = { ... } }，讓某些類別的審批保持互動式，而其他類別自動拒絕。細粒度策略覆蓋沙箱審批、execpolicy 規則提示、MCP 提示（mcp_elicitations）、request_permissions 提示以及技能指令碼審批。

自動審批審查

預設情況下，審批請求會直接發給你：

approvals_reviewer = "user"

只有在審批保持互動式時，自動審批審查才會生效，例如 approval_policy = "on-request" 或細粒度審批策略。把 approvals_reviewer = "auto_review" 後，符合條件的審批請求會先交給審查智能體，再由 Codex 執行對應請求：

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

如需檢視完整審查生命週期、觸發條件、設定優先順序和失敗行為，請參見自動審查。

審查智能體只會檢查那些原本就需要審批的動作，例如沙箱升級、被阻止的網路請求、request_permissions 提示，或會產生副作用的 app / MCP 工具呼叫。已經在當前沙箱邊界內允許執行的動作仍會直接執行，不會額外經過審查。

審查策略會檢查資料外洩、憑據探測、持續性安全削弱，以及破壞性操作。低風險和中風險動作會在策略允許時繼續；關鍵風險動作會被拒絕；高風險動作只有在使用者授權足夠且沒有命中拒絕規則時才會繼續。建置提示詞、審查會話和解析失敗都會按失敗關閉處理。超時會單獨呈現，但動作仍不會執行。

預設審查策略位於開源 Codex 儲存庫中。企業可以在託管 requirements 中使用 guardian_policy_config 覆蓋其中與租戶相關的策略部分。本機也支援使用 [auto_review].policy，但託管 requirements 的優先順序更高。設定方式見託管設定。

在 ChatGPT 桌面版中，這類審查會顯示為自動審查條目，狀態可能包括 Reviewing、Approved、Denied、Aborted、Timed out，並可能附帶本次請求的風險等級和使用者授權評估。

自動審查會額外消耗模型呼叫，因此會增加 Codex 使用量。管理員可以通過 allowed_approvals_reviewers 約束是否允許使用它。

常見的沙箱與審批組合

對於非互動執行，請使用 codex exec --sandbox workspace-write；Codex 仍保留較舊的 codex exec --full-auto 呼叫作為已棄用的相容路徑，並會列印警告。

當你使用 --ask-for-approval untrusted 時，Codex 只會自動執行已知安全的只讀操作。那些可能改變狀態或觸發外部執行路徑的命令，例如破壞性的 Git 操作，或帶 Git 輸出或設定覆蓋 flag 的命令，都需要審批。

config.toml 中的設定

更完整的設定工作流程，請結合基礎設定、高階設定和設定參考一起閱讀。

# 始终请求审批的模式
approval_policy = "untrusted"
sandbox_mode    = "read-only"
allow_login_shell = false # 可选加固：禁止基于 shell 的工具使用 login shell

# 可选：在 workspace-write 模式下允许联网
[sandbox_workspace_write]
network_access = true

# 可选：细粒度审批策略
# approval_policy = { granular = {
#   sandbox_approval = true,
#   rules = true,
#   mcp_elicitations = true,
#   request_permissions = false,
#   skill_approval = false
# } }

你也可以把這些預設儲存為設定檔檔案，然後通過 codex --profile profile-name 選擇：

# ~/.codex/full_auto.config.toml
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode    = "read-only"

在本機測試沙箱

如果你想觀察某條命令在 Codex 沙箱下執行時會發生什麼，可以使用下面這些 Codex CLI 命令：

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

sandbox 命令也可以通過 codex debug 使用；平台輔助命令還有別名，例如 codex sandbox seatbelt 和 codex sandbox landlock。

作業系統級沙箱

Codex 會根據不同作業系統以不同方式強制執行沙箱：

• macOS：使用 Seatbelt 策略，並通過 sandbox-exec 結合與你所選 --sandbox 模式對應的設定檔（-p）執行命令。當受限讀取權限啟用平台預設規則時，Codex 會附加一套精心篩選的 macOS 平台策略，而不是寬泛地放開 /System，以儘量保持常見工具相容性。
• Linux：預設使用 bwrap 配合 seccomp。
• Windows：在 Windows Subsystem for Linux 2 (WSL2) 中執行時使用 Linux 沙箱實現。WSL1 在 Codex 0.114 之前仍可使用；從 0.115 開始，Linux 沙箱切換到了 bwrap，因此 WSL1 不再受支援。在 Windows 原生環境中執行時則使用Windows 沙箱實現。

如果你在 Windows 上使用 Codex IDE 擴充套件，它可以直接支援 WSL2。你可以在 VS Code 設定中加入以下內容，以便在可用時始終讓智能體執行在 WSL2 內：

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

這樣即使宿主機是 Windows，IDE 擴充套件也會繼承 Linux 的命令、審批和檔案系統存取沙箱語義。更多內容請參見 WSL 指南。

如果你是在 Windows 原生環境中執行 Codex，可以在 config.toml 中設定原生沙箱模式：

[windows]
sandbox = "unelevated" # or "elevated"
# sandbox_private_desktop = true  # default; set false only for compatibility

更多細節請參見 Windows 設定指南。

如果你在 Docker 這類容器化環境中執行 Linux，而宿主機或容器設定阻止了 Codex 所需的 namespace、setuid bwrap 或 seccomp 操作，沙箱可能無法工作。

此時應由 Docker 容器本身提供你需要的隔離，然後在容器內部使用 --sandbox danger-full-access，或 --dangerously-bypass-approvals-and-sandbox，來執行 codex。

在 Dev Containers 中執行 Codex

如果宿主機無法直接執行 Linux 沙箱，或者你的組織已經標準化使用容器化開發，可以在 Dev Containers 中執行 Codex，並讓 Docker 提供外層隔離邊界。這適用於 Visual Studio Code Dev Containers 以及相容工具。

可以把 Codex secure devcontainer 範例作為參考實現。該範例會安裝 Codex、常見開發工具、bubblewrap，並提供基於防火牆的出站存取控制。

參考實現包含：

• 安裝了 Codex 和常見開發工具的 Ubuntu 24.04 基礎映象；
• 基於允許列表的出站防火牆設定檔；
• 用於在容器中重新開啟工作區的 VS Code 設定和擴充套件推薦；
• 命令歷史和 Codex 設定的持久化掛載；
• bubblewrap，讓容器授予所需能力時，Codex 仍可使用自己的 Linux 沙箱。

試用步驟：

1. 安裝 Visual Studio Code 和 Dev Containers 擴充套件。
2. 把 Codex 範例 .devcontainer 設定複製到你的儲存庫中，或直接從 Codex 儲存庫開始。
3. 在 VS Code 中執行 Dev Containers: Open Folder in Container...，並選擇 .devcontainer/devcontainer.secure.json。
4. 容器啟動後，開啟終端並執行 codex。

也可以從 CLI 啟動容器：

devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

這個範例主要由三部分組成：

• .devcontainer/devcontainer.secure.json 控制容器設定、capabilities（能力）、掛載、環境變數和 VS Code 擴充套件。
• .devcontainer/Dockerfile.secure 定義基於 Ubuntu 的映象和安裝工具。
• .devcontainer/init-firewall.sh 應用出站網路策略。

參考防火牆只是一個起點。如果你依賴域名允許列表來做隔離，請實現適合你環境的 DNS rebinding 和 DNS 重新整理保護，例如支援 TTL 的重新整理邏輯或具備 DNS 感知能力的防火牆。

在容器內部，可以選擇以下模式之一：

• 如果 Dev Container 設定檔授予了 bwrap 建立內層沙箱所需的能力，就保留 Codex 的 Linux 沙箱。
• 如果容器本身就是你預期的安全邊界，請在容器內使用 --sandbox danger-full-access 執行 Codex，避免 Codex 再嘗試建立第二層沙箱。

版本控制

Codex 在配合版本控制工作流程時效果最佳：

• 在委派任務前先切到功能分支，並保持 git status 乾淨。這樣更容易隔離和回滾 Codex 生成的補丁。
• 相比直接編輯已跟蹤檔案，更推薦基於補丁的工作流程，例如 git diff / git apply。同時要頻繁提交，以便小步回退。
• 像審查普通 PR 一樣對待 Codex 的建議：執行有針對性的驗證、審查 diff，並在提交資訊中記錄決策以便審計。

監控與遙測

Codex 支援基於 OpenTelemetry（OTel）的可選監控，幫助團隊在不削弱本機預設安全邊界的前提下進行審計、問題調查和合規支援。遙測預設關閉，必須在設定中顯式啟用。

概覽

• 預設情況下，Codex 會關閉 OTel 匯出，以保持本機執行自包含。
• 啟用後，Codex 會發出結構化日誌事件，覆蓋聊天、API 請求、SSE / WebSocket 流活動、使用者提示詞（預設脫敏）、工具審批決策和工具結果。
• Codex 會給匯出事件打上 service.name（來源方）、CLI 版本和環境標籤，用於區分 dev / staging / prod 流量。

啟用 OTel（可選）

在 Codex 設定中加入 [otel] 塊，通常位於 ~/.codex/config.toml，然後選擇匯出器並決定是否記錄提示詞文本：

[otel]
environment = "staging"    # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false    # 除非策略允许，否则脱敏提示词文本

• exporter = "none" 會保留埋點，但不會把資料發到任何地方。
• 如果你要把事件傳送到自有采集端，可以選擇其一：

[otel]
exporter = { otlp-http = {
  endpoint = "https://otel.example.com/v1/logs",
  protocol = "binary",
  headers = { "x-otlp-api-key" = "${OTLP_TOKEN}" }
}}

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://otel.example.com:4317",
  headers = { "x-otlp-meta" = "abc123" }
}}

Codex 會批次傳送事件，並在退出時重新整理緩衝。Codex 只會匯出由自身 OTel 模組產生的遙測資料。

事件類別

代表性事件類型包括：

• codex.conversation_starts：模型、推理設定以及沙箱或審批策略
• codex.api_request：請求次數、狀態 / 成功與否、耗時和錯誤細節
• codex.sse_event：流事件類型、成功 / 失敗、耗時，以及 response.completed 上的 token 計數
• codex.websocket_request 和 codex.websocket_event：請求耗時，以及每條訊息的類型 / 成功 / 錯誤
• codex.user_prompt：長度；除非顯式開啟，否則內容會被脫敏
• codex.tool_decision：是否核准 / 拒絕，以及決策來源是設定還是使用者
• codex.tool_result：耗時、成功與否以及輸出片段

對應的 OTel 指標也包含計數器和耗時直方圖，例如 codex.api_request、codex.sse_event、codex.websocket.request、codex.websocket.event 和 codex.tool.call，以及相應的 .duration_ms 指標。

完整事件目錄和設定參考，請參見 GitHub 上的 Codex 設定文件。

安全與隱私建議

• 除非你的策略明確允許儲存提示詞內容，否則應保持 log_user_prompt = false。提示詞中可能包含源程式碼和敏感資料。
• 遙測只應傳送到你自己可控的採集端，並按合規要求設定保留期和存取控制。
• 工具參數和工具輸出也應視為敏感資料；如有可能，優先在採集端或 SIEM 層做脫敏。
• 如果你不希望 Codex 在 CODEX_HOME 下儲存會話記錄，請檢查本機資料保留設定，例如 history.persistence 和 history.max_bytes。參見高階設定和設定參考。
• 如果 CLI 執行時關閉了網路存取，OTel 匯出將無法連線到你的採集端。若要匯出，需要在 workspace-write 模式中允許存取 OTel 端點，或者在 Codex 雲端把採集端域名加入允許列表。
• 應定期審查匯出事件，重點關注審批 / 沙箱變更以及異常的工具執行。

OTel 是可選項，它的設計目標是補充上文的沙箱與審批保護，而不是替代它們。

託管設定

企業管理員可以在託管設定中為工作區設定 Codex 安全設定。關於具體的設定方式和策略細節，請參見該頁。

來源：</zh-TW/docs/agent-approvals-security> 更新時間：2026-05-19（UTC）