交流群即将上线
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 密钥登录， 那样连审计都丢了。