Appearance
配置系统 — 概念
config.toml 结构
config.toml 是 Codex 的主配置文件,由 config crate(codex-rs/config/src/)管理:
config.toml 的核心配置段:
| 配置段 | 说明 | 对应模块 |
|---|---|---|
[model] | 模型选择和参数 | config_toml |
[sandbox] | 沙箱策略配置 | permissions_toml |
[mcp_servers] | [[glossary/mcp | MCP]] 服务器定义 |
[hooks] | 生命周期钩子 | hook_config |
[skills] | 技能配置 | skills_config |
[profiles] | 命名配置 profile | profile_toml |
JSON Schema 验证
配置系统使用 Schema 验证确保配置值的类型安全和语义正确:
验证体系的核心类型:
| 类型 | 说明 | 模块 |
|---|---|---|
ConfigError | 配置错误枚举 | config/src/lib.rs |
ConfigLoadError | 加载错误 | config/src/lib.rs |
Constrained<T> | 带约束的配置值 | constraint |
ConstraintResult | 约束检查结果 | constraint |
ConfigRequirements | 配置需求定义 | config_requirements |
Diagnostics | 错误诊断信息 | diagnostics |
Constrained<T> 包装配置值,在访问时自动执行约束检查,确保运行时始终使用有效配置。
多级配置合并
Codex 的配置系统采用分层合并策略,通过 ConfigLayerSource 追踪每个配置值的来源:
配置合并的关键机制:
LoaderOverrides:CLI 参数作为最高优先级覆盖,覆盖任何文件或云端配置CloudConfigBundle:从云端拉取的配置层,支持组织级策略管理cloud_config_layers:云端配置可能包含多个层(组织策略、团队配置、用户偏好)config_layer_source:每个配置值记录其来源(CLI/Cloud/Local/Global/Default),便于调试和诊断fingerprint:配置指纹用于检测配置变更,触发运行时重新加载
rust
pub struct CloudConfigBundleLoader {
// 从云端加载配置
}
pub struct LoaderOverrides {
// CLI 参数覆盖
pub model: Option<String>,
pub sandbox: Option<SandboxablePreference>,
// ...
}配置项详解
主要配置项及其作用:
| 配置项 | 类型 | 默认值 | 说明 |
|---|---|---|---|
model | String | 平台默认 | 使用的 LLM 模型 |
sandbox | SandboxablePreference | Auto | 沙箱策略(Auto/Require/Forbid) |
approval_policy | ApprovalPolicy | 交互式决定 | 命令审批策略 |
mcp_servers | HashMap<String, McpServerConfig> | 空 | MCP 服务器配置 |
hooks | HooksToml | 空 | 生命周期钩子 |
skills | SkillsConfig | 空 | 技能配置 |
profiles | HashMap<String, Profile> | 空 | 命名配置 profile |
HooksToml 定义了生命周期钩子:
rust
pub struct HooksToml {
pub hooks: HashMap<HookEventsToml, Vec<HookHandlerConfig>>,
}
pub enum HookEventsToml {
// 生命周期事件类型
}
pub struct HookHandlerConfig {
// 钩子处理器配置
}相关概念
- Config.toml — 主配置文件
- Sandbox — 沙箱策略配置
- MCP — MCP 服务器配置
- ExecPolicy — 执行策略配置
- Ephemeral — 临时执行环境配置