Codex CLI 的 YOLO 模式：設定、指令與沙盒停用風險解析

簡而言之，codex --yolo 是 codex --dangerously-bypass-approvals-and-sandbox 的簡短別名。它將審核設定為「永不」，並將沙盒設定為「完全危險存取」。這第二部分很不尋常，因為 Claude Code 和 Gemini CLI 的 YOLO 模式只會跳過提示，但會保留沙盒功能，而 Codex 則兩者都移除。

這兩個設定是獨立的：codex -a never -s workspace-write 讓你可以「永不詢問，但仍受限制」，這通常是大多數人真正想要的。沙盒提供真實的作業系統隔離，例如 macOS 上的 Seatbelt (sandbox-exec)、Linux/WSL2 上的 bubblewrap + seccomp、Windows 上的原生沙盒，以及 WSL1 上的無沙盒。

codex exec 從不要求審核，因此在 CI 環境中，沙盒是唯一重要的設定。以下所有指令都已於 2026 年 10 月 7 日，根據 openai/codex 的 72c9595 版本 (0.161.0 版)、@agentclientprotocol/codex-acp 2.1.1 和 OpenAI 的 Codex 文件進行了驗證。

這兩個設定是什麼？Codex 將安全性建模為兩個獨立的維度：審核政策 (approval_policy) 決定何時詢問你，其 CLI 旗標為 -a 或 --ask-for-approval，可選值為 on-request (預設)、never 或更細緻的表格。

沙盒模式 (sandbox_mode) 決定指令可以存取什麼，其 CLI 旗標為 -s 或 --sandbox，可選值為 read-only、workspace-write 或 danger-full-access。

on-request 表示當模型想要執行沙盒會阻擋的操作時，它可能會停止並詢問你。沙盒隨後會在作業系統層級決定哪些檔案可寫以及是否有網路存取權限。

由於這些設定是獨立的，你會得到一個 2x3 的行為網格。其中值得注意的組合包括：codex -a never -s danger-full-access 等同於 codex --yolo；codex -a never -s workspace-write 則表示永不詢問但仍受沙盒保護；而 codex -a on-request -s danger-full-access 則表示沒有沙盒保護，但仍可能（儘管很少）詢問你。

中間的組合（永不詢問，但仍受沙盒保護）有一個很好的失敗模式：當指令需要超出沙盒允許的權限時，它會直接失敗，錯誤會回傳給模型來處理。這過程中沒有人為介入，但也沒有逃逸風險。在 CLI 中，-a 僅接受 on-request 和 never。

同時設定兩個相同選項的旗標將會被拒絕：--yolo 不能與 -a 結合，而 --approve-for-me 也不能與 -a、-s 或 --yolo 結合使用。

為什麼 Codex 的 YOLO 模式也會停用沙盒？因為該旗標本身的說明文字指出，它適用於已經從外部進行沙盒隔離的環境（它稱自己為「極度危險」）。其設計假設是：如果你告訴 Codex「永不詢問」，你可能身處於容器、虛擬機器或 CI 執行器中，在這些環境下，內部的沙盒只會增加摩擦。這個假設在 CI 環境中非常有用，但在你的個人筆記型電腦上則非常糟糕。

以下是 danger-full-access 實際的含義。它不只是「專案」，而是你的使用者帳戶可以存取的一切：所有你可以讀寫的檔案，例如 ~/.ssh、~/.aws、~/.config/gcloud、瀏覽器設定檔、其他儲存庫和點檔案。

它還包括不受限制的網路存取，可以下載並執行程式、使用任何找到的 token 呼叫 API，並竊取任何資料。你的 Git 身分也不再受保護，因此歷史重寫和 git push --force 會以你的名義執行。此外，啟動 Codex 的 shell 中所有匯出的環境變數也都會被存取。

現在，再加上提示詞注入的風險。README、問題或擷取的網頁中的惡意指令可以引導模型，而當 YOLO 模式開啟時，沒有任何機制會暫停並詢問你。

沙盒是如何建構的？在 macOS 上，它透過 sandbox-exec 使用內建的 Seatbelt 機制，無需安裝任何東西。Linux 則使用 bubblewrap 和 seccomp 網路過濾器，它會從 PATH 或內建副本中使用 bwrap。

舊的 Landlock 後端已是舊版，不適用於檔案系統受限的政策。WSL2 與 Linux 相同，而 WSL1 則沒有沙盒，因為它無法建立 bubblewrap 所需的使用者命名空間，因此 Codex 會拒絕沙盒指令。原生 Windows 則使用 Codex 自己的沙盒，有非提升權限和提升權限兩種變體，其中 /setup-default-sandbox 會設定提升權限的沙盒。

Linux 的情況比較棘手。bubblewrap 需要非特權使用者命名空間，但在非特權容器中，這些命名空間通常不可用，你會收到啟動警告，且沙盒無法啟動。這是唯一一種在容器內執行 --yolo 是正常設定而非捷徑的情況，因為容器本身就是沙盒。

即使在 workspace-write 模式下，Codex 仍會將 .git、.codex 和 .agents 保持為唯讀，因此它無法在未經詢問的情況下重寫歷史或其自身的配置。這是一個巧妙的細節：代理程式自己的控制平面位於其寫入限制之外。

如何在不完全停用沙盒的情況下，獲得大部分 YOLO 模式的功能？大多數對 YOLO 的需求來自於 workspace-write 的兩個限制：沒有網路存取和無法寫入專案外部。你可以單獨開啟這些功能：將 sandbox_mode 設定為 `