mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Abhinav
ab26554a3a
## Why Customers need finer-grained control over allowed sandbox modes based on the host Codex is running on. For example, they may want stricter sandbox limits on devboxes while keeping a different default elsewhere. Our current cloud requirements can target user/account groups, but they cannot vary sandbox requirements by host. That makes remote development environments awkward because the same top-level `allowed_sandbox_modes` has to apply everywhere. ## What Adds a new `remote_sandbox_config` section to `requirements.toml`: ```toml allowed_sandbox_modes = ["read-only"] [[remote_sandbox_config]] hostname_patterns = ["*.org"] allowed_sandbox_modes = ["read-only", "workspace-write"] [[remote_sandbox_config]] hostname_patterns = ["*.sh", "runner-*.ci"] allowed_sandbox_modes = ["read-only", "danger-full-access"] ``` During requirements resolution, Codex resolves the local host name once, preferring the machine FQDN when available and falling back to the cleaned kernel hostname. This host classification is best effort rather than authenticated device proof. Each requirements source applies its first matching `remote_sandbox_config` entry before it is merged with other sources. The shared merge helper keeps that `apply_remote_sandbox_config` step paired with requirements merging so new requirements sources do not have to remember the extra call. That preserves source precedence: a lower-precedence requirements file with a matching `remote_sandbox_config` cannot override a higher-precedence source that already set `allowed_sandbox_modes`. This also wires the hostname-aware resolution through app-server, CLI/TUI config loading, config API reads, and config layer metadata so they all evaluate remote sandbox requirements consistently. ## Verification - `cargo test -p codex-config remote_sandbox_config` - `cargo test -p codex-config host_name` - `cargo test -p codex-core load_config_layers_applies_matching_remote_sandbox_config` - `cargo test -p codex-core system_remote_sandbox_config_keeps_cloud_sandbox_modes` - `cargo test -p codex-config` - `cargo test -p codex-core` unit tests passed; `tests/all.rs` integration matrix was intentionally stopped after the relevant focused tests passed - `just fix -p codex-config` - `just fix -p codex-core` - `cargo check -p codex-app-server`
ab26554a3a
·
2026-04-21 05:05:02 +00:00
History
codex-core config loader
This module is the canonical place to load and describe Codex configuration layers (user config, CLI/session overrides, managed config, and MDM-managed preferences) and to produce:
- An effective merged TOML config.
- Per-key origins metadata (which layer “wins” for a given key).
- Per-layer versions (stable fingerprints) used for optimistic concurrency / conflict detection.
Public surface
Exported from codex_core::config_loader:
load_config_layers_state(fs, codex_home, cwd_opt, cli_overrides, overrides, cloud_requirements, thread_config_loader, host_name) -> ConfigLayerStackConfigLayerStackeffective_config() -> toml::Valueorigins() -> HashMap<String, ConfigLayerMetadata>layers_high_to_low() -> Vec<ConfigLayer>with_user_config(user_config) -> ConfigLayerStack
ConfigLayerEntry(one layer’s{name, config, version, disabled_reason};namecarries source metadata)LoaderOverrides(test/override hooks for managed config sources)merge_toml_values(base, overlay)(public helper used elsewhere)
Layering model
Precedence is top overrides bottom:
- MDM managed preferences (macOS only)
- System managed config (e.g.
managed_config.toml) - Session flags (CLI overrides, applied as dotted-path TOML writes)
- User config (
config.toml)
Thread config entries supplied by thread_config_loader are inserted according
to their translated ConfigLayerSource precedence.
Layers with a disabled_reason are still surfaced for UI, but are ignored when
computing the effective config and origins metadata. This is what
ConfigLayerStack::effective_config() implements.
Typical usage
Most callers want the effective config plus metadata:
use codex_core::config_loader::{CloudRequirementsLoader, LoaderOverrides, load_config_layers_state};
use codex_config::NoopThreadConfigLoader;
use codex_exec_server::LOCAL_FS;
use codex_utils_absolute_path::AbsolutePathBuf;
use toml::Value as TomlValue;
let cli_overrides: Vec<(String, TomlValue)> = Vec::new();
let cwd = AbsolutePathBuf::current_dir()?;
let layers = load_config_layers_state(
LOCAL_FS.as_ref(),
&codex_home,
Some(cwd),
&cli_overrides,
LoaderOverrides::default(),
CloudRequirementsLoader::default(),
&NoopThreadConfigLoader,
/*host_name*/ None,
).await?;
let effective = layers.effective_config();
let origins = layers.origins();
let layers_for_ui = layers.layers_high_to_low();
Internal layout
Implementation is split by concern:
state.rs: public types (ConfigLayerEntry,ConfigLayerStack) + merge/origins convenience methods.layer_io.rs: readingconfig.toml, managed config, and managed preferences inputs.overrides.rs: CLI dotted-path overrides → TOML “session flags” layer.merge.rs: recursive TOML merge.fingerprint.rs: stable per-layer hashing and per-key origins traversal.macos.rs: managed preferences integration (macOS only).