I was looking through the recent Codex commit Harden project config when credential brokering is active.
The practical change is quite specific. Codex now tracks credential brokering as unconfigured, disabled, or enabled. When the broker is active, project-controlled configuration is prevented from supplying shell snapshots, profile loading, ZDOTDIR, BASH_ENV, and credential-provider environment variables. When brokering is disabled, those project shell settings are preserved.
What caught my attention is the order of operations. The effective broker requirements are calculated before the project layers are sanitized and merged. This is not just “managed configuration wins.” The project layer is no longer allowed to participate in that part of the decision once the broker owns it.
The new tests cover both active and disabled broker states, protected provider variables, and shell startup settings. To me, they support a narrow claim: an enabled broker removes the demonstrated project-controlled inputs from its decision surface. They do not prove complete credential isolation or containment after a credential has been issued.
Two implementation questions seem worth discussing:
- As credential providers add new inputs, should ownership be expressed as typed capabilities instead of a growing protected-key list?
- Should Codex emit a value-free diagnostic when a project setting is ignored, recording the policy and broker state without recording the setting’s value?
The second point would make reload and incident debugging easier while keeping credential material out of logs.