交流群即將上線
05 · 配置檔案與團隊統一
先看清六層優先順序
Codex 從多個位置讀配置，從高到低是：
- CLI 標誌和
--config覆蓋 - 專案配置
.codex/config.toml，從專案根到當前工作目錄逐級排列，離當前目錄最近的優先（僅限受信任的專案） - 配置方案檔案
~/.codex/profile-name.config.toml，用--profile profile-name選 - 使用者配置
~/.codex/config.toml - 系統配置
/etc/codex/config.toml（Unix） - 內建預設值
用法上很清楚：共用的預設值寫 config.toml，配置方案檔案裡只寫要覆蓋的那幾項。
CLI 和 IDE 擴充功能共用同一套配置層。IDE 裡開啟配置檔案的路徑是 右上角齒輪 → Codex 設定 → 開啟 config.toml。
「受信任的專案」是個安全開關，不是麻煩
Codex 只在你信任某個專案時才載入它的 .codex/ 配置層。 標記為不受信任時，Codex 會跳過專案本地的配置、鉤子和規則； 使用者級和系統級的仍然載入。
想想這為什麼重要：.codex/config.toml 是跟著倉庫來的。 如果 clone 一個陌生倉庫就自動載入它的配置， 對方可以給你配一個 MCP 伺服器（本地啟動程序）、 一套鉤子（在特定時機跑指令）、一份規則（放寬沙盒外的指令）。
所以「這個專案要不要信任」是一次真實的安全判斷，別一路回車過去。
一份夠用的個人配置
toml
# ~/.codex/config.toml
# 审批与沙盒（详见 /start/04-approvals）
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = false
# 子智能体：先把并发数框住
[agents]
max_concurrent_threads_per_session = 6
# 指令文件的回退名（如果团队用别的名字）
# project_doc_fallback_filenames = ["TEAM_GUIDE.md"]
# project_doc_max_bytes = 65536配置方案：按場景切換
不同的活需要不同的預設值。與其每次敲一長串標誌，不如存成方案：
toml
# ~/.codex/readonly_quiet.config.toml
approval_policy = "never"
sandbox_mode = "read-only"toml
# ~/.codex/deep_review.config.toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
model_reasoning_effort = "high"bash
codex --profile readonly_quiet
codex exec --profile deep_review "review this change"一次性覆蓋用 -c：
bash
codex -c 'features.network_proxy=true' -c 'sandbox_workspace_write.network_access=true'TOML 的引號規則有點講究，寫複雜值之前看一眼高階配置。
團隊統一：分清兩條線
這是最容易搞混的地方。團隊級的東西分成建議和強制兩條線， 它們放在不同的地方、由不同的人管。
建議線：提交進倉庫
跟著程式碼走，誰 clone 誰得到：
| 型別 | 放哪 | 管什麼 |
|---|---|---|
| 配置 | .codex/config.toml | 倉庫的預設設定 |
| 規則 | .codex/rules/*.rules | 沙盒外執行哪些指令需要核准 |
| 技能 | .agents/skills/ | 倉庫範圍可複用的工作流 |
| 指令 | AGENTS.md | 怎麼在這個倉庫裡幹活 |
注意這條線的能力上限：倉庫配置能給預設設定和可複用工作流， 但授不了工作區、模型、平臺 API 或已連線系統的存取權限。 而且它只在專案被信任時生效。
強制線：requirements.toml
管理員通過雲端、裝置或系統渠道分發 requirements.toml， 約束本地執行時的行為。這是真正的硬約束——比如禁掉 approval_policy = "never" 或 sandbox_mode = "danger-full-access"。
現在推薦的寫法是權限配置方案，不是圍繞舊的沙盒模式限制來設計：
toml
default_permissions = ":workspace"
[allowed_permission_profiles]
":read-only" = true
":workspace" = true要在瀏覽器端和桌面端全面關掉計算機使用，得把相關的每個功能鍵都關掉：
toml
[features]
browser_use = false
browser_use_full_cdp_access = false
browser_use_external = false
in_app_browser = false
computer_use = false這個策略要和 ChatGPT 工作區的角色、群組分開管理—— 一個管裝置上的執行時行為，一個管誰能登入、能用哪些介面。
落地的順序
在團隊裡推 Codex，按這個順序阻力最小：
- 先在倉庫裡放
AGENTS.md。成本最低、見效最快，而且不改任何人的權限。 - 再補
.codex/config.toml，統一模型和預設核准策略。 - 然後把重複流程做成技能，提交到
.agents/skills/。 - 最後才碰
requirements.toml。這是強制線，先把前三步跑順、 知道大家實際怎麼用之後再定，否則你會在限制一些其實沒人會做的事。
反過來做——一上來就下發強制策略——通常的結果是有人繞過它去用 API 金鑰登入， 那樣連審計都丟了。