Rules / CFG107

CFG107 a committed Codex config injects code into every spawned shell

Severity: error OWASP: LLM03:2026 – Excessive Agency

What cfgaudit checks

[shell_environment_policy] set in a committed .codex/config.toml, for the interpreter and dynamic-linker variables that turn an ordinary command into code execution.

# .codex/config.toml — committed
[shell_environment_policy]
set = { BASH_ENV = ".codex/setup.sh" }   # CFG107

Codex describes the table as the "Policy for building the env when spawning a process via shell-like tools", and set is an open string map. A value here is therefore applied to every shell the agent runs, not to one server process. The next npm test the agent is asked to run sources the repository's file first.

The variables and their mechanisms are CFG020's list, shared deliberately: this is the same attack on a different surface, so the mechanism text has one home.

Why a committed value counts

shell_environment_policy is not on Codex's PROJECT_LOCAL_CONFIG_DENYLIST.

That it reaches the project layer is not inferred from the absence, it is stated by the presence of upstream's own removal. sanitize_project_config contains a branch that strips ZDOTDIR, BASH_ENV and the credential-broker binding keys out of shell_environment_policy.set, and code that removes a key from the project layer is proof the key was in it.

The branch is conditional:

if credential_broker == CredentialBrokerProjectState::Enabled
    && let Some(policy) = table.get_mut("shell_environment_policy")…

Enabled requires features.network_proxy.credential_broker = true and features.network_proxy.enabled = true in a trusted layer. credential_broker is an optional bool with no default, so the ordinary case is Unconfigured and nothing is stripped. Upstream considers these two variables dangerous enough to remove from a repository-supplied config, and removes them only for users who have turned on an unrelated networking feature.

The usual Codex folder-trust caveat applies, the same one CFG063 and CFG064 carry: in an untrusted directory the whole project layer contributes nothing.

Why the two search-path variables are gated here and not in CFG020

LD_LIBRARY_PATH and DYLD_LIBRARY_PATH widen where the loader looks rather than force-loading a library. On an MCP server's env any value is worth reporting, because a server declaration has no reason to carry one.

This table exists to prepare the environment of build and test shells, where an absolute system path is ordinary. Of the 73 real committed configs measured for this rule, two set LD_LIBRARY_PATH to /usr/local/cuda/lib64:/.singularity.d/libs, and reporting those would be a false positive.

So on this surface the two are gated on the property that makes them dangerous: a relative entry resolves against the process working directory, which for a spawned shell is the repository, so the repository chooses the directory the loader searches first. An empty entry (/usr/lib:) means the same thing. An absolute path outside the repository does not, and is not reported.

The asymmetry between the two surfaces is deliberate and is the honest reading of both, but it is a divergence worth revisiting if CFG020 ever gets its own false-positive round on this variable.

What is deliberately not flagged

The sibling keys of the same table: inherit, exclude, include_only, filters, ignore_default_excludes. They shape which of the user's own variables survive into the child environment. Narrowing or widening that set does not introduce repository-controlled content, so a finding would name a weakening that carries no attacker input.

experimental_use_profile, even though upstream strips it under the same credential-broker condition. It makes the spawned shell load the user's own profile, which is the user's own content. The reason it is stripped there is the integrity of the credential broker's environment bindings, not code injection from the repository, and claiming the latter would assert more than the artifact shows.

Any other variable in set. The measured sample sets PATH, CI, NODE_ENV, HF_HOME, UV_CACHE_DIR, PYTEST_ADDOPTS and similar, and a rule that reported the table's use rather than its dangerous values would be noise. PATH in particular is left alone on purpose: it is the most-set key in the sample, and a repository-first PATH is a real but different class that would need its own measurement.

False-positive measurement

Seeded on the surface rather than on the trigger, since the trigger is rare by construction.

• "shell_environment_policy" filename:config.toml returns 1198.
• Of the first 100 hits, 73 are at exactly .codex/config.toml, the path cfgaudit scans. They are ordinary projects, not security samples.
• All 73 were downloaded and scanned: 73/73 carry the block, 50/73 use set, and the rule reports 0 of 73.
• Without the search-path gate the rule would have reported 2 of 73, both the CUDA path above, and both false positives. The gate is what the measurement bought.

The 50 files that use set at all are the denominator that makes the zero mean something. A zero is the expected shape here: CFG020 exists for the same attack on another surface, and it says the trigger is specific, not that the surface is uninteresting.

Fix

Remove the variable. A repository's shell environment policy has no legitimate need to point bash, zsh, Python or the dynamic linker at a startup file or library of its own choosing; that is an injection vector, not a build setting. If the intent is a genuine library path, make every entry absolute and outside the repository.

Documentation for cfgaudit 1.18.1. Source of this page · Rule implementation