Precedence Is Not Configuration Authority
Layered configuration usually answers one question: when several sources provide a value, which value wins? That question is not enough for security-sensitive inputs. A project can lose the final precedence contest and still retain influence over shell startup, provider selection or environment construction before the winning value is used.
A Codex maintainer change merged on 2026-08-25 makes the distinction concrete. When credential brokering is effectively enabled, the project-controlled layer loses access to selected shell snapshot and profile settings and to protected environment keys, including ZDOTDIR, BASH_ENV and broker-recognized provider inputs. When brokering is disabled, ordinary project configuration remains available.
The bounded design lesson is: configuration precedence ranks admitted values; configuration authority decides who is admitted to the decision. Once an effective policy transfers control of provider and startup inputs to a credential broker, a lower-trust project layer should not be able to recover that control by supplying competing values.
A winning value can still leave the wrong participant in the room
Suppose managed configuration declares the intended credential provider at the highest precedence. A repository also supplies shell startup settings and environment variables that affect how that provider is reached. If the merge algorithm merely selects the managed value while preserving all lower-layer inputs, the project still participates in a decision that the broker is supposed to own.
This is why a precedence-only account is misleading. It treats every layer as a legitimate participant and resolves conflict only after participation has occurred. A security boundary needs an earlier question: is this layer authorized to express this input in the current runtime state?
The selected change answers that question narrowly. It distinguishes Unconfigured, Disabled and Enabled broker states, resolves effective network requirements, and applies project-layer suppression only when the broker is actually authoritative. The important operation is not that one value outranks another. The broker-owned decision surface is removed from project control.
Effective state turns ownership into an executable rule
State-dependent suppression avoids the opposite mistake: converting a security boundary into a permanent global denylist. In the disabled branch, project shell settings remain legitimate because no broker has taken ownership of those decisions. In the enabled branch, the same settings are no longer accepted from that layer.
That behavior gives authority a monotonic property at the demonstrated boundary. Enabling the broker can narrow what a lower-trust layer controls; the project cannot widen its authority again through an ordinary merge. Disabling the broker deliberately restores the normal surface.
This ordering matters on reload and resume. A runtime should first recompute effective broker state, then decide which layers may contribute, and only then merge admitted values. Reapplying project configuration before authority is known recreates the very window the boundary is meant to close.
The regression coverage is also part of the argument. Tests for both enabled and disabled branches show that the rule follows ownership state rather than merely deleting a fixed list of settings everywhere.
An authority boundary creates maintenance and audit obligations
Removing protected keys is only as complete as the protected-key classifier. Providers evolve. New environment inputs appear. A list that is correct today can quietly become porous if ownership metadata does not evolve with the provider interface.
A stronger design would attach authority ownership to typed configuration capabilities: provider endpoint, credential source, startup-file redirection, trusted binding and similar categories. The runtime could then reject lower-layer contributions by capability rather than relying entirely on an expanding list of string keys.
Suppression should also be observable without exposing values. Operators need to know that a project attempted to set a broker-owned input, which policy suppressed it, and which authority state was effective. They do not need the secret-bearing value itself. Such events make reload and incident review auditable while preserving confidentiality.
Finally, ownership must be documented per layer. The selected evidence removes the demonstrated project layer. It does not say whether user, host, managed-policy or process-level sources are intentionally authorized. Those are separate trust decisions, not conclusions that follow from project hardening.
A narrow boundary is not universal credential isolation
The merged implementation and its tests establish a useful project/configuration boundary while brokering is enabled. They do not prove end-to-end non-exfiltration, isolation from every higher source, transactional shell execution or containment after a credential has legitimately been issued.
This distinction prevents security language from outrunning evidence. The defensible claim is that the demonstrated lower-trust layer cannot control the protected broker and startup inputs in the enabled branch. The remaining questions are operational: how the protected set evolves, which higher layers retain authority, whether reload recomputes ownership first, and how suppression is audited without recording secrets.
Primary evidence: Codex merged commit fd1bf504. The public implementation and branch-specific regressions support this bounded configuration-authority conclusion; they are not independent validation of universal credential isolation.