Once a coding agent can run shells, access a network, and work in a repository, a small configuration question becomes a trust question: which layer decides how a credential reaches a command? A merged Codex pull request puts the broker’s enablement and provider context in trusted configuration, not the project.
The change adds credential brokering to the network-proxy configuration, then prevents the project itself from changing the broker’s enablement or provider context when that broker has been configured in a trusted layer.
That matters because repository configuration is collaborative by design. It is often reviewed, copied, forked, and changed to make a task run. Credentials are not. The story here is not that Codex has found a magical way to make secrets safe; it is that the implementation chooses a different owner for the decision to broker them.
Configuration stops at the repository door
The public commit adds features.network_proxy. and treats the network-proxy feature as structured configuration rather than a loose boolean.
More importantly, its loader strips a project’s attempt to set the broker, set the network-proxy toggle, or replace the provider-context environment keys once trusted broker configuration exists. The same path carries trusted context into a filtered shell environment. In plain language: the repository can still be the place an agent learns the job, without also becoming the place that decides the credential plumbing.
A brokered shell is not an escalated shell
The implementation does not blur every execution mode together. Its approval-suite test sets up a GitHub host and a fixture token, runs a command through the zsh-fork runtime, and asserts that the command output does not contain the real token while the broker reports active.
Separately, the changed escalation code restores brokered credentials for an explicitly unsandboxed command. That distinction is the useful design pressure: a masked or brokered environment can serve a constrained task, while a higher-trust transition is made in one visible place rather than accidentally inheriting the same authority.
There is a limit worth keeping in view. The evidence is a main-branch change and test suite, not a release note, a default-on promise, or a field report from a deployed organisation. The next useful signal is public configuration documentation that names the supported providers and explains the behavior across sandboxed and escalated commands. Until then, teams evaluating the feature should audit their configuration layers—not assume that a broker has erased the need for a credential policy.