智能體審批與安全

Codex 有助於保護你的程式碼和資料，並降低被濫用的風險。

預設情況下，智能體執行時會關閉網路存取。在本機，Codex 使用由作業系統強制執行的沙箱來限制其可存取的範圍（通常僅限當前工作區），並通過審批策略控制它必須在何時停止操作並先徵得你的同意。

如需從整體上了解沙箱在 ChatGPT 桌面應用、 Codex CLI 和 IDE 擴充套件中的工作方式，請參閱沙箱。 如需更全面的企業安全概述，請參閱 Codex 安全白皮書。

從已停用的 untrusted 審批策略遷移

Codex 和 ChatGPT Work 不再支援 approval_policy = "untrusted"。 這項已停用的設定可能導致這兩個客戶端無法啟動。請從 使用者或專案設定、設定檔、啟動指令碼以及受管理的 預設設定中移除它。對於互動式只讀使用場景：

sandbox_mode = "read-only"
approval_policy = "on-request"

或者執行 codex --sandbox read-only --ask-for-approval on-request。

使用 on-request 時，沙箱允許的命令無須審批即可執行， 可以讀取有權存取的檔案，並在網路存取已啟用時使用網路。

若要保留更嚴格的命令審批規則，請不要顯式設定 approval_policy，並在使用者級 ~/.codex/config.toml 中新增專案條目：

[projects."/path/to/project"]
trust_level = "untrusted"

此後，命令需要獲得審批，除非執行策略規則允許執行。 這也會停用專案本機設定。顯式設定 on-request 會覆蓋從專案派生的策略；受管理的 allowed_approval_policies 必須 包含 untrusted 才能允許使用該策略。

沙箱與審批

Codex 的安全控制由兩個協同工作的層級構成：

• 沙箱模式：Codex 執行模型生成的命令時，在技術層面能夠執行哪些操作（例如可寫入哪些位置以及能否存取網路）。
• 審批策略：Codex 在執行操作前必須於何時徵得你的同意（例如離開沙箱、使用網路或執行受信任集合之外的命令）。

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

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

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

Codex 在編輯工作區之外的檔案或執行需要網路存取的命令前會徵求核准。如果你只想聊天或制定計劃而不進行更改，請使用 /permissions 命令切換到 read-only 模式。

對於宣告會產生副作用的應用（連接器）工具呼叫，Codex 也可以請求審批，即使該操作並非 shell 命令或檔案更改。只要工具聲明瞭破壞性註解，破壞性的應用/MCP 工具呼叫始終需要審批（除非工具同時聲明瞭優先順序更高的讀取註解）。

安全監控和暫停的任務

GPT-6 Astra 在 Codex 和 ChatGPT Work 中包含安全監控功能。監控會 非同步執行，並在檢測到可能不安全的模型行為時暫停任務。 暫停可能在觸發監控的活動發生後才出現；監控 不能替代沙箱、權限或結果審查。

如果任務暫停，請閱讀通知，並在有審查結果時仔細檢視。僅在確認 任務可以安全繼續後再恢復。如果通知顯示任務 已結束，或沒有提供恢復選項，則無法從該 介面恢復任務。

安全監控會評估任務執行期間的模型行為。 自動審批審查會評估那些在執行前 本就需要審批的具體操作。經自動審批審查核准的操作 仍可能屬於之後被監控暫停的任務。

網路存取

對於 Codex cloud，請參閱智能體網際網路存取，瞭解如何啟用完整網際網路存取或域名允許列表。

對於 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 會話，如果只需開關此功能，請使用布林值簡寫； 如果還要設定策略選項，請使用表格形式：

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'

該功能會改變已啟用的網路存取的執行方式；它本身並不授予 網路存取權限。使用 sandbox_workspace_write.network_access 及 workspace-write 設定來決定命令究竟能否存取網路：

• 網路關閉 + network_proxy 開啟：網路仍保持關閉，該功能不起作用。
• 網路開啟 + network_proxy 關閉：網路保持開啟，並可不受限制地直接 向外存取。
• 網路開啟 + network_proxy 開啟：網路保持開啟，出站流量 受已設定的網路策略約束。

代理功能也適用於權限設定檔。 設定檔中的 network.enabled = true 授予命令網路存取權限，而 features.network_proxy = true 會啟用對該設定檔域名 規則的強制執行：

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

如果在此範例中省略代理功能，命令將擁有直接網路 存取權限，且 api.openai.com 允許規則不會限制其目標地址。

由管理員管理的 experimental_network 要求與使用者的 功能開關相互獨立。它們可以在沒有 features.network_proxy 的情況下設定並啟動沙箱網路，但噹噹前 沙箱保持網路關閉時，它們不會開啟網路存取。有關管理員側 requirements.toml 的結構，請參閱託管設定。

網路策略

域名規則以允許列表優先：

• 精確主機規則僅匹配該主機本身。
• *.example.com 匹配 api.example.com 等子域名，但不匹配 example.com。
• **.example.com 同時匹配頂級域名和子域名。
• 全域 * 允許規則匹配任何未被拒絕的公共主機。請將 * 視為寬泛的網路存取，並儘可能優先使用範圍明確的規則。
• deny 的優先順序始終高於 allow，且全域 * 僅可用於允許規則。

本機和私有目標

預設情況下，allow_local_binding = false 會阻止環回、鏈路本機和 私有目標：

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

DNS 重繫結防護

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

• 查詢失敗或超時會被阻止。
• 解析到非公共地址的主機名會被阻止。
• 該檢查可以降低 DNS 重繫結風險，但無法完全消除風險。要徹底防止 重繫結，需要在傳輸層固定解析後的 IP。

如果威脅範圍包含惡意 DNS，還應在更底層實施出站控制。

危險設定

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

• dangerously_allow_non_loopback_proxy = true 可能會將代理監聽器暴露到 環回地址之外。
• dangerously_allow_all_unix_sockets = true 會繞過 Unix 套接字允許列表。

僅在受到嚴格控制的環境中使用它們。啟用 Unix 套接字代理後， 即使請求了非環回繫結，監聽器仍僅限環回地址， 因此沙箱網路不會成為進入本機守護程序的遠端橋樑。

network_proxy 預設關閉。啟用後：

命令網路代理之外的流量

網路代理會過濾在本機命令沙箱內執行的指令碼、程式和 子程序。它不會過濾網頁搜尋、應用或 連接器工具呼叫、MCP 伺服器連線、瀏覽器或 Computer Use 活動、 Codex cloud 任務，也不會過濾客戶端的模型請求和身份驗證請求。這些 功能面使用各自獨立的服務連線、功能設定、工作區 策略或環境控制。

瀏覽器工具在存取 origin 前，還會單獨檢查託管網路拒絕規則和排他性允許列表。 瀏覽器 origin 策略可進一步限制網站 存取、上傳、下載和開發者工具。請參閱 託管瀏覽器控制。

對於託管使用者，請將命令網路策略與 allowed_web_search_modes、已核准的 mcp_servers 以及針對應用、外掛、瀏覽器或 Computer Use 的 功能要求等控制措施結合使用。請參閱 託管設定。

你還可以單獨控制網頁搜尋工具，而無需向啟動的命令授予完整網路存取權限。Codex 預設使用網頁搜尋快取來存取結果。該快取是由 OpenAI 維護的網頁結果索引，因此快取模式傳回預先建立索引的結果，而不是即時取得頁面。這可以減少任意即時內容中提示詞注入帶來的風險，但你仍應將網頁結果視為不可信內容。如果你使用 --yolo 或其他完整存取沙箱設定，網頁搜尋將預設傳回即時結果。使用 --search 或將 web_search = "live" 設定為允許即時瀏覽，也可以將其設定為 "disabled" 以關閉該工具：

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

如果外部網頁存取應由搜尋索引把關，請設定 web_search = "indexed"。 在 Codex 中啟用網路存取或網頁搜尋時請保持謹慎。 提示詞注入可能導致智能體取得並遵循不可信的指令。

預設設定與建議

• 啟動時，Codex 會檢測資料夾是否受版本控制，並建議：
  • 受版本控制的資料夾：Auto（工作區寫入 + 按請求審批）
  • 不受版本控制的資料夾：read-only
• 根據你的設定，在你明確將工作目錄設為可信之前（例如通過初始設定提示或 /permissions），Codex 也可能以 read-only 啟動。
• 工作區包括當前目錄以及 /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 提示、request_permissions 提示以及技能指令碼審批。

自動審批審查

預設情況下，審批請求會傳送給你：

approvals_reviewer = "user"

自動審批審查適用於互動式審批，例如 approval_policy = "on-request" 或精細化審批策略。設定 approvals_reviewer = "auto_review" 後，符合條件的審批請求會先由審查智能體 稽核，之後 Codex 才會執行相應請求：

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

有關完整的審查器生命週期、觸發條件、設定優先順序 和失敗行為，請參閱 自動審查。

審查器僅評估本就需要審批的操作，例如沙箱 權限提升、被阻止的網路請求、request_permissions 提示，或 會產生副作用的應用和 MCP 工具呼叫。沙箱內的操作 無需額外審查即可繼續執行。

審查器策略會檢查資料外洩、憑據探測、持續性的 安全弱化以及破壞性操作。策略允許時，低風險和中風險操作 可以繼續執行。策略會拒絕嚴重風險操作。 高風險操作必須獲得充分的使用者授權，且不能匹配任何拒絕規則。 提示詞建置、審查會話和解析失敗時會以拒絕方式安全終止。超時會 單獨顯示，但相應操作仍不會執行。

預設審查器策略 位於開源 Codex 儲存庫中。企業可以在託管要求中使用 guardian_policy_config 替換其中的租戶專屬部分。 也支援本機 [auto_review].policy 文本，但託管要求的優先順序 更高。有關設定詳情，請參閱 託管設定。

在 ChatGPT 桌面應用中，這些審查會顯示為自動審查項，其狀態 可能為 Reviewing、Approved、Denied、Aborted 或 Timed out。它們還可以 包含風險等級以及對受審查請求的使用者授權評估。

自動審查會額外呼叫模型，因此可能增加 Codex 用量。管理員 可以使用 allowed_approvals_reviewers 對其進行限制。

常見的沙箱與審批組合

對於非互動式執行，請使用 codex exec --sandbox workspace-write；Codex 會將舊版 codex exec --full-auto 呼叫保留為已棄用的相容路徑，並顯示警告。

config.toml 中的設定

有關更全面的設定流程，請參閱設定基礎、高階設定和設定參考。

# Interactive approvals with a read-only sandbox
approval_policy = "on-request"
sandbox_mode    = "read-only"
allow_login_shell = false # optional hardening: disallow login shells for shell-based tools

# Optional: Allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true

# Optional: granular approval policy
# 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 上以原生方式執行時，Codex 使用 Windows 沙箱實現。

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

{
  "chatgpt.runCodexInWindowsSubsystemForLinux": true
}

這樣可以確保即使主機作業系統是 Windows，IDE 擴充套件也會沿用 Linux 的命令、審批和檔案系統存取沙箱語義。有關更多資訊，請參閱 WSL 指南。

在 Windows 上以原生方式執行時，請在 config.toml 中設定原生沙箱模式：

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

有關詳情，請參閱 Windows 設定指南。

在 Docker 等容器化環境中執行 Linux 時，如果主機或容器設定阻止了 Codex 所需的名稱空間、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 安全 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 控制容器設定、能力、掛載、環境變數和 VS Code 擴充套件。
• .devcontainer/Dockerfile.secure 定義基於 Ubuntu 的映象及安裝的工具。
• .devcontainer/init-firewall.sh 應用出站網路策略。

參考防火牆有意僅作為起點。如果你依賴域名允許列表實現隔離，請採用適合你環境的 DNS 重繫結和 DNS 重新整理防護，例如可感知 TTL 的重新整理機制或可感知 DNS 的防火牆。

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

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

版本控制

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

• 在功能分支上工作，並在委派前保持 git status 乾淨。這樣更容易隔離和還原 Codex 補丁。
• 與直接編輯已跟蹤檔案相比，應優先採用基於補丁的工作流程（例如 git diff/git apply）。經常提交，以便能夠按較小的增量回滾。
• 像對待任何其他 PR 一樣對待 Codex 的建議：執行有針對性的驗證、審查差異，並在提交訊息中記錄決策以供審計。

監控與遙測

Codex 支援選擇啟用基於 OpenTelemetry (OTel) 的監控，幫助團隊審計使用情況、調查問題並滿足合規要求，同時不削弱本機安全預設設定。遙測預設關閉；請在設定中明確啟用。

概述

• Codex 預設關閉 OTel 匯出，使本機執行保持自包含狀態。
• 啟用後，Codex 會發出結構化日誌事件，涵蓋聊天、API 請求、SSE/WebSocket 流活動、使用者提示詞（預設遮蓋）、工具審批決策和工具結果。
• Codex 會使用 service.name（發起方）、CLI 版本和環境標籤標記匯出的事件，以區分開發/預發布/生產流量。

啟用 OTel（選擇啟用）

在 Codex 設定（通常為 ~/.codex/config.toml）中新增 [otel] 塊，並選擇匯出器以及是否記錄提示詞文本。

[otel]
environment = "staging"   # dev | staging | prod
exporter = "none"          # none | otlp-http | otlp-grpc
log_user_prompt = false     # redact prompt text unless policy allows

• 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 cloud 匯出，並將收集器域名加入已核准列表。
• 定期檢查事件，關注審批/沙箱變更和意外的工具執行。

OTel 是可選功能，旨在補充而非取代上述沙箱和審批保護措施。

託管設定

企業管理員可以在託管設定中為其工作區設定 Codex 安全設定。有關設定和策略詳情，請參閱該頁面。