Codex config.toml in Practice: Approval Modes × Sandbox Isolation × Profiles
A ready-to-paste ~/.codex/config.toml template that sets up OpenAI Codex CLI's approval policy, sandbox isolation, reasoning effort, and multiple profiles in one go — balancing automation efficiency with safety boundaries.
你是我的 Codex CLI 設定助手。請依下列規格,幫我產生 / 檢視 `~/.codex/config.toml`,並逐項解釋每個鍵的安全含義。我的需求如下:
專案根目錄:{{PROJECT_ROOT}}
預設模型:{{MODEL}}(例:gpt-5.5)
預設推理強度:{{REASONING_EFFORT}}(minimal / low / medium / high / xhigh 擇一)
我要的安全預設:{{DEFAULT_SAFETY}}(保守 / 平衡 / 全自動 擇一)
請輸出一份完整 config.toml,至少包含:
# ===== 全域預設(最保守,避免誤觸)=====
model = "{{MODEL}}"
model_reasoning_effort = "{{REASONING_EFFORT}}"
# approval_policy 控制 Codex 何時停下來問你:
# untrusted = 每個未受信指令都要核可(最囉嗦、最安全)
# on-request = 由模型自行判斷何時請求核可(官方預設、平衡)
# never = 完全不問、全自動(只配合受限沙箱才安全)
approval_policy = "on-request"
# sandbox_mode 控制檔案系統 / 網路權限:
# read-only = 完全唯讀,不能改任何檔(適合純偵錯 / code review)
# workspace-write = 只能改工作區內檔案(日常開發推薦)
# danger-full-access = 無限制(危險,僅在外層已有容器隔離時用)
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false # 預設關閉對外網路,要裝套件再臨時開
writable_roots = [{{EXTRA_WRITABLE_PATHS}}] # 額外允許寫入的目錄(如 build 輸出)
exclude_slash_tmp = false
# 標記哪些專案可信,否則 Codex 不會載入該專案的 .codex/ 設定、hooks、rules
[projects."{{PROJECT_ROOT}}"]
trust_level = "trusted"
# ===== 設定檔(用 --profile 名稱 快速切換工作模式)=====
[profiles.readonly] # codex --profile readonly:純讀程式碼、不改檔
approval_policy = "never"
sandbox_mode = "read-only"
[profiles.dev] # codex --profile dev:日常開發,改工作區要核可
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[profiles.full_auto] # codex --profile full_auto:CI / 大批改,全自動但仍鎖在工作區
approval_policy = "never"
sandbox_mode = "workspace-write"
[profiles.full_auto.sandbox_workspace_write]
network_access = {{CI_NEEDS_NETWORK}}
產出後,請額外做三件事:
1. 用一段話說明我選的 {{DEFAULT_SAFETY}} 對應到哪組鍵值、為什麼。
2. 標出哪些鍵「不能」在專案層 .codex/config.toml 覆寫(如 model_provider、profiles、notify),避免我誤以為改了有效。
3. 給我三條對應指令範例:唯讀偵錯一條、日常開發一條、CI 全自動一條。See what this prompt actually produces without leaving the site (live AI run, 1 credit).
Don't just copy-paste — download and drop it at ~/.codex/prompts/config-toml-approval-sandbox-modes.md then invoke it with /config-toml-approval-sandbox-modes.
mkdir -p ~/.codex/prompts && mv ~/Downloads/config-toml-approval-sandbox-modes.md ~/.codex/prompts/config-toml-approval-sandbox-modes.mdNew-Item -ItemType Directory -Force "$env:USERPROFILE\.codex\prompts" | Out-Null; Move-Item "$env:USERPROFILE\Downloads\config-toml-approval-sandbox-modes.md" "$env:USERPROFILE\.codex\prompts\config-toml-approval-sandbox-modes.md"## What it is, what problem it solves OpenAI Codex CLI's default behavior is easy to get wrong in both directions: set it too tight, and it stops to ask for your approval on every shell command and every file edit, turning batch tasks into an endless string of Enter-presses; set it too loose (e.g. fully automatic), and you risk it corrupting files or making outbound network requests while you're not watching. The real fix isn't choosing between 'annoying' and 'dangerous' — it's separating the two orthogonal dimensions of 'approval policy' and 'sandbox isolation' in `~/.codex/config.toml`, then using profiles to switch between a few common combinations depending on the task. This piece distills that setup into a ready-to-paste template with Chinese-language comments explaining every value. ## Why this source is worth using This is based on the community-maintained awesome-codex-cli list (CC0 public domain), which catalogs Codex CLI's configuration surface and ecosystem tools; the specific key names and allowed values are aligned with OpenAI's official Config Reference (config.toml has 85+ properties). We picked out only the security-related keys that matter most and are most commonly confused, and explained the real-world consequences of each value clearly, rather than just copying a long property table. ## The two core dimensions The first dimension is `approval_policy` (when it stops to ask you): `untrusted` asks for approval on every untrusted action — safest but noisiest; `on-request` lets the model decide for itself when to ask for approval, and is the official default, well-balanced for daily use; `never` never asks at all, fully automatic, and is only safe when the sandbox itself is tight enough. The second dimension is `sandbox_mode` (what it's allowed to touch): `read-only` can't write any files at all, good for pure code review and debugging; `workspace-write` can only modify files inside the workspace, the recommended value for daily development; `danger-full-access` has no restrictions and should only be used when an outer container already provides isolation. Crossing these two dimensions lets you build practical profiles like 'read-only debugging,' 'workspace writable,' and 'fully automatic CI.' ## How to use it (steps) 1. Paste the template into `~/.codex/config.toml`, filling in the model, reasoning effort, and project paths. 2. Under `[sandbox_workspace_write]`, turn `network_access` off by default, and only enable it temporarily when you need to install packages or fetch data — this avoids the task silently phoning home. 3. Use `[projects."<path>".trust_level = "trusted"]` to mark trusted projects; for untrusted projects Codex skips that project's own .codex config, hooks, and rules — an important gate against malicious repos smuggling in settings. 4. Set up three profiles — `readonly`, `dev`, and `full_auto` — so you can switch instantly later with `codex --profile dev`. 5. Remember that some keys (model_provider, profiles, notify, and auth/telemetry-related settings) can't be overridden at the project level — don't casually edit them in a repo's own .codex/config.toml. ## When to use it The first time you install Codex CLI, or when a team wants to standardize its security baseline; when getting ready to wire Codex into CI (which needs `never` plus a restricted `workspace-write`); and any time you find yourself thinking 'why does it keep asking me' or, conversely, 'how dare it just change that' — both usually trace back to these two keys being set wrong. 📎 Source: RoggeOhta/awesome-codex-cli (by RoggeOhta, CC0-1.0 public domain) + key values aligned with OpenAI's official Codex Config Reference — this piece is a rewritten and reorganized version; see the link above for the original content.
[PROJECT_ROOT]你的專案根目錄絕對路徑,用於 trust_level 標記
[MODEL]預設模型 ID,例如 gpt-5.5
[REASONING_EFFORT]推理強度:minimal / low / medium / high / xhigh 擇一
[DEFAULT_SAFETY]你要的安全預設傾向:保守 / 平衡 / 全自動
[EXTRA_WRITABLE_PATHS]工作區外額外允許寫入的路徑陣列,例如 "/tmp/build",沒有就留空
[CI_NEEDS_NETWORK]填下面的欄位,上方 prompt 會即時替換 [方括號] 內容。填好後按「複製組好的 prompt」直接丟進工具。
你是我的 Codex CLI 設定助手。請依下列規格,幫我產生 / 檢視 `~/.codex/config.toml`,並逐項解釋每個鍵的安全含義。我的需求如下:
專案根目錄:{{PROJECT_ROOT}}
預設模型:{{MODEL}}(例:gpt-5.5)
預設推理強度:{{REASONING_EFFORT}}(minimal / low / medium / high / xhigh 擇一)
我要的安全預設:{{DEFAULT_SAFETY}}(保守 / 平衡 / 全自動 擇一)
請輸出一份完整 config.toml,至少包含:
# ===== 全域預設(最保守,避免誤觸)=====
model = "{{MODEL}}"
model_reasoning_effort = "{{REASONING_EFFORT}}"
# approval_policy 控制 Codex 何時停下來問你:
# untrusted = 每個未受信指令都要核可(最囉嗦、最安全)
# on-request = 由模型自行判斷何時請求核可(官方預設、平衡)
# never = 完全不問、全自動(只配合受限沙箱才安全)
approval_policy = "on-request"
# sandbox_mode 控制檔案系統 / 網路權限:
# read-only = 完全唯讀,不能改任何檔(適合純偵錯 / code review)
# workspace-write = 只能改工作區內檔案(日常開發推薦)
# danger-full-access = 無限制(危險,僅在外層已有容器隔離時用)
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false # 預設關閉對外網路,要裝套件再臨時開
writable_roots = [{{EXTRA_WRITABLE_PATHS}}] # 額外允許寫入的目錄(如 build 輸出)
exclude_slash_tmp = false
# 標記哪些專案可信,否則 Codex 不會載入該專案的 .codex/ 設定、hooks、rules
[projects."{{PROJECT_ROOT}}"]
trust_level = "trusted"
# ===== 設定檔(用 --profile 名稱 快速切換工作模式)=====
[profiles.readonly] # codex --profile readonly:純讀程式碼、不改檔
approval_policy = "never"
sandbox_mode = "read-only"
[profiles.dev] # codex --profile dev:日常開發,改工作區要核可
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[profiles.full_auto] # codex --profile full_auto:CI / 大批改,全自動但仍鎖在工作區
approval_policy = "never"
sandbox_mode = "workspace-write"
[profiles.full_auto.sandbox_workspace_write]
network_access = {{CI_NEEDS_NETWORK}}
產出後,請額外做三件事:
1. 用一段話說明我選的 {{DEFAULT_SAFETY}} 對應到哪組鍵值、為什麼。
2. 標出哪些鍵「不能」在專案層 .codex/config.toml 覆寫(如 model_provider、profiles、notify),避免我誤以為改了有效。
3. 給我三條對應指令範例:唯讀偵錯一條、日常開發一條、CI 全自動一條。Suno Engineer's Mindset: 4 Steps to a Song That Doesn't Sound Like AI
A studio engineer's breakdown of Suno's fatal weaknesses (fried vocals, high-frequency artifacts), plus a 4-step DAW workflow and a Suno Studio cleanup prompt.
5 Claude Weekly Workflows That Stuck After 6 Months
Proposal generator / meeting processor / content repurposer / Friday review / shutdown reset — out of 40 I tried, only these 5 survived, each saving 30+ minutes per run.