Module config 

Read-side access to $CODEX_HOME/config.toml.

Requires the config feature, which is off by default: it pulls in a TOML parser, and a caller that never reads config should not pay for one.

This matters more than it used to. Several exec options moved from flags to config keys in 0.145.0 (approval_policy, web_search), so config is where some behavior is now decided, and a host reporting or overriding effective settings would otherwise parse the file itself.

What is typed and what is not

Only the keys this wrapper has a reason to know about are typed. Everything else stays in CodexConfig::raw as parsed TOML. Modelling the whole file would mean tracking a schema that changes every release, and a key this crate cannot name is not a key it should hide.

Profiles are files, not a table

Verified against codex-cli 0.145.0: --profile <name> layers $CODEX_HOME/<name>.config.toml over the base config, so the available profiles are the *.config.toml files in the home directory.

A [profiles] table in config.toml is the legacy mechanism. The CLI now refuses to write one, reporting that it “contains legacy config profile tables and can no longer be written”. Any such table is reported separately as CodexConfig::legacy_profiles rather than mixed in with the real ones.

Example

if let Some(config) = codex_wrapper::config::load()? {
    println!("model:    {:?}", config.model);
    println!("profiles: {:?}", config.profiles);
}

Structs

CodexConfig

The parsed contents of config.toml, plus the profiles beside it.

Functions

load

Read the config for the current environment.

load_from_home

load, but against an explicit CODEX_HOME.