代理核准與安全性

Codex 有助於保護您的程式碼與資料，並降低遭濫用的風險。

預設情況下，智慧體執行時會關閉網路存取。在本機，Codex 使用由作業系統強制執行的沙盒，限制其可存取的範圍，通常是目前的工作區，並透過核准政策控管其必須在何時停止並徵詢您的同意，才能執行動作。

如需概略瞭解沙盒在 ChatGPT 桌面版應用程式、 Codex CLI 與 IDE 擴充功能中的運作方式，請參閱 沙盒。 如需更全面的企業安全性概覽，請參閱 Codex 安全性白皮書。

沙盒與核准

Codex 的安全控管分成兩個相互配合的層級：

• 沙盒模式：Codex 執行模型生成的指令時，技術上可以執行哪些動作，例如可寫入哪些位置，以及能否存取網路。
• 核准政策：Codex 必須在執行哪些動作前徵詢您的同意，例如離開沙盒、使用網路，或執行不在受信任集合中的指令。

Codex 會根據執行環境採用不同的沙盒模式：

• Codex 雲端：在由 OpenAI 管理的隔離容器中執行，防止存取您的主機系統或不相關的資料。採用兩階段執行模型：設定階段在智慧體階段之前執行，並可存取網路以安裝指定的相依套件；接著，智慧體階段預設會離線執行，除非您為該環境啟用網際網路存取。為雲端環境設定的機密資訊僅能在設定階段使用，並會在智慧體階段開始前移除。
• Codex CLI／IDE 擴充功能：由作業系統層級的機制強制執行沙盒政策。預設不允許網路存取，且寫入權限僅限於使用中的工作區。您可以根據自身的風險承受度設定沙盒、核准政策與網路設定。

使用 Auto 預設組態時，例如 --sandbox workspace-write --ask-for-approval on-request，Codex 可以自動在工作目錄中讀取檔案、進行編輯及執行指令。

若要編輯工作區以外的檔案，或執行需要網路存取的指令，Codex 會要求核准。如果您只想對話或規劃而不進行變更，請使用 /permissions 指令切換至 read-only 模式。

即使動作並非 Shell 指令或檔案變更，Codex 也可針對標示會產生副作用的應用程式（連接器）工具呼叫要求核准。當應用程式／MCP 工具標示破壞性註記時，其破壞性工具呼叫一律需要核准；但如果工具也標示讀取註記，則以讀取註記為優先。

網路存取 Elevated Risk

若使用 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 工作階段，若只需要開關，請使用 布林簡寫；若同時要設定政策選項，則使用表格形式：

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 socket 允許清單。

這些設定只能用於嚴格控管的環境。啟用 Unix socket 代理功能時， 即使要求繫結至非回送位址，監聽器仍只會繫結至回送位址， 因此沙盒網路不會成為通往本機常駐程式的遠端橋接通道。

network_proxy 預設為關閉。啟用後：

指令網路代理伺服器未涵蓋的流量

網路代理伺服器會篩選在本機指令沙盒中執行的指令碼、程式及子行程，但不會篩選網頁搜尋、應用程式或連接器工具呼叫、MCP 伺服器連線、瀏覽器或電腦功能的活動、Codex 雲端任務，以及用戶端的模型與身分驗證要求。這些功能各自使用獨立的服務連線、功能設定、工作區政策或環境控制機制。

對於受管理的使用者，請將指令網路政策搭配其他控制措施，例如 allowed_web_search_modes、已核准的 mcp_servers，以及適用於 應用程式、外掛程式、瀏覽器或電腦的功能要求。請參閱 受管理的設定。

您也可以控制網頁搜尋工具，而不必授予所啟動的指令完整的網路存取權。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
• 視您的設定而定，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-rule 提示、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 桌面版應用程式中，這些審查會顯示為自動審查項目，並標示「審查中」、「已核准」、「已拒絕」、「已中止」或「已逾時」等狀態。這些項目也可能包含受審查要求的風險等級，以及使用者授權評估。

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

常見的沙盒與核准組合

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

使用 --ask-for-approval untrusted 時，Codex 只會自動執行已知安全的讀取操作。可能改變狀態或觸發外部執行路徑的指令（例如破壞性的 Git 操作，或 Git 輸出／組態覆寫旗標）都需要核准。

config.toml 中的組態

如需了解更完整的組態工作流程，請參閱基本設定、進階設定及組態參考資料。

# Always ask for approval mode
approval_policy = "untrusted"
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 搭配設定檔（-p）執行指令；此設定檔對應您選擇的 --sandbox 模式。當受限讀取權限啟用平台預設設定時，Codex 會附加經篩選的 macOS 平台政策，而非廣泛允許存取 /System，以維持常用工具的相容性。
• Linux 預設使用 bwrap 搭配 seccomp。
• Windows 在 Windows Subsystem for Linux 2 (WSL2) 中執行時，會使用 Linux 沙盒實作。Codex 至 0.114 版本仍支援 WSL1；從 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 容器以提供所需的隔離，然後在容器內執行 codex 並加上 --sandbox danger-full-access（或 --dangerously-bypass-approvals-and-sandbox 旗標）。

在 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: 在容器中開啟資料夾... ，然後選取 .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 版本及環境標籤標記匯出的事件，以區分 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     # 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 雲端匯出。
• 請定期審查事件，檢查核准或沙盒是否有變更，以及是否出現非預期的工具執行。

OTel 是選用功能，旨在補強而非取代上述沙盒與核准保護。

受管理的設定

企業管理員可在受管理的設定中，為工作區進行 Codex 安全性設定。設定方式與政策詳情請參閱該頁面。