Codex Project Config Just Got a Trust Boundary. Treat It Like One.

Codex configuration just moved from “developer preference” to “security boundary,” which is exactly where coding-agent config was always going to end up.

OpenAI’s refreshed Codex configuration reference now says a project-scoped .codex/config.toml is loaded only after the user trusts the project. More importantly, the repo-local file cannot override machine-local provider, auth, host-owned app request metadata, notification, profile selection, or telemetry routing keys. Codex explicitly ignores openai_base_url, chatgpt_base_url, apps_mcp_product_sku, model_provider, model_providers, notify, profile, profiles, experimental_realtime_ws_base_url, and otel when they appear in project-local config.

That sounds like a tiny docs update until you remember what Codex is allowed to be. It is not just a text editor with a better autocomplete model. It can read source trees, run shell commands, call MCP tools, operate through app surfaces, use plugins, and participate in remote-control flows. Once an agent can act, the configuration file that shapes those actions becomes part of the execution environment. Treating it like harmless repo metadata is how teams end up reviewing infrastructure after the incident instead of before it.

The repo should not get to pick the agent’s identity

The most important line OpenAI drew is between project workflow and machine authority. A repository can reasonably express preferences about how work should happen in that repository. It should not be able to redirect the agent to a different provider endpoint, pick a privileged profile, change telemetry routing, or smuggle notification behavior into a developer’s machine. Those are identity and governance decisions, not project settings.

This is the same distinction platform teams already apply elsewhere. A repo can include ESLint config, TypeScript settings, test commands, Docker files, and deployment descriptors. It cannot, or should not, decide which corporate identity provider you use, where audit logs go, which secrets are mounted, or which machine-level proxy is trusted. Coding agents collapse enough boundaries already. The least they can do is keep provider, auth, telemetry, notification, and profile selection out of repo control.

Codex’s related security docs reinforce the same model. By default, network access is off. In local workspace-write mode, Codex can read files, edit the active workspace, and run commands there, but it must ask before leaving the workspace or using network access. The docs also describe network proxy allow/deny rules, protections for private and loopback destinations, DNS-rebinding checks, and approval requirements for destructive app or MCP tool calls when tools advertise destructive annotations. The product direction is clear: useful autonomy, constrained by explicit policy.

Project trust is a real approval, not a vibes button

The phrase “Codex loads project-scoped config files only when you trust the project” deserves more attention than it will get. Developers are trained to click through trust prompts because the prompt is usually blocking them from doing work. With an agent, that click has higher meaning. It is the moment repo-controlled preferences start influencing a system that can edit code, execute commands, discover tools, and potentially interact with external services.

That makes .codex/config.toml closer to a supply-chain artifact than a local convenience file. Teams already worry about package.json scripts, GitHub Actions workflows, Dockerfiles, Makefile targets, and dependency lockfiles because they influence execution. Agent config belongs on that list. The review question is not “is this TOML valid?” It is “what would this make the agent do differently, and who benefits from that change?”

The keys OpenAI blocks locally tell you where the dangerous edges are. Provider URLs can redirect model traffic. Model provider definitions can change who receives prompts and code context. Profiles can select a different bundle of permissions and defaults. Notification hooks can leak workflow state. Telemetry routing can alter auditability. App request metadata can affect hosted surfaces. None of those should be silently inherited from a repo someone cloned five minutes ago.

There is also a useful enterprise parallel in the Codex GitHub issue tracker. One open issue asks for MCP server registry discovery with centralized governance: OAuth and dynamic client registration, per-user authorization, scope-based access, and audit trails. That request exists because ad hoc MCP URLs do not scale. If every repo gets to imply its own tool universe, the organization loses the ability to answer basic questions: which tools were available, which identities were used, what data could be reached, and what changed after the agent ran?

The practical policy is boring, which is why it might work

Engineering teams should turn this docs update into a checklist, not a Slack shrug. First, audit repositories for .codex/config.toml. If you find one, review it the way you would review CI configuration or developer-container configuration. Second, decide which project-local keys are allowed in your environment. Third, keep provider, auth, telemetry, notification, and profile selection at user, device-management, or enterprise-managed levels. Fourth, add project trust to onboarding docs so developers understand what they are approving.

For sensitive repositories, the safer default is read-only or constrained workspace-write until the config and tool surface are reviewed. For unknown repositories, especially public repos used during research, Codex should not inherit more authority just because the repo includes agent-friendly configuration. If the project needs special permissions, the burden should be on the maintainer to document why.

MCP governance needs the same discipline. Maintain an allowlist of approved servers. Separate read-only tools from mutating tools. Require destructive annotations and approvals for anything that changes external systems. Document which servers are safe for default availability and which should be enabled only per task. A project-local config file should not be a shortcut around that policy.

The broader industry pattern is obvious now. GitHub is moving Copilot plugins into enterprise-managed standards. OpenAI is limiting what project-local Codex config can override. Agent tools are becoming governed runtime surfaces, not personal productivity toys. Good. The alternative is every repository becoming its own tiny agent administrator, with all the accountability of a sticky note.

The editorial take: this is the kind of unglamorous boundary that determines whether coding agents survive contact with real engineering organizations. Project config is useful. Repo-owned identity, provider routing, telemetry, profiles, and notifications are not. If Codex wants to be trusted as an agent runtime, drawing that line is not optional plumbing. It is the product.

Sources: OpenAI Developers — Codex Configuration Reference, OpenAI Developers — Advanced Configuration, OpenAI Developers — Agent approvals & security, OpenAI Codex issue #25750, OpenAI Codex issue #26498