Codex Exec Missing MCP Servers? Check Project Trust Before Sandbox Settings

Codex 0.169.0 keeps project-local configuration and MCP servers disabled in untrusted directories during codex exec, even when you select --sandbox workspace-write. If a noninteractive job has lost a tool, check project trust before widening its sandbox. File-write access does not authorize loading commands from a repository.

The stable release notes describe this as a fix and introduce explicit trust for codex exec and codex review. This guide reviews the released implementation and its tests; it does not claim a hands-on migration test.

Two different permissions can produce the same symptom

Imagine a repository with an MCP server configured in .codex/config.toml. Your local interactive setup can use it, but an automated review job cannot. The tempting diagnosis is that the job needs a more permissive sandbox. In this release, that may be the wrong layer entirely: Codex can decline to load the project configuration before it gets to running the requested tool.

The implementation change keeps project trust explicit in noninteractive runs. It also adds a warning when project-local configuration is disabled. Capture that warning rather than reducing the failure to “MCP is broken.”

This distinction matters when the repository is not yours. A project can contain useful instructions and also define commands you would not choose to run on your machine. Giving an agent permission to edit that checkout should not automatically authorize the checkout's integration setup.

What --trust actually changes

The released CLI definition describes --trust as saving trust for the project and future chats, including MCP commands outside the sandbox. It persists even with --ephemeral and does not override a project explicitly marked untrusted.

Treat this as a lasting configuration decision, not a one-run repair flag. Before granting it, inspect the project's configuration, the MCP executable and arguments, and the origin of anything those commands load. If the checkout comes from an unfamiliar contributor, leave its project configuration disabled until someone responsible for the environment has reviewed it.

For an approved project, the flag is available on codex exec or codex review. Do not add it indiscriminately to a wrapper that runs against arbitrary repositories. Such a wrapper would turn a per-project decision into a standing approval for whatever checkout arrives next.

Diagnose disabled configuration separately from a broken server

The tagged integration test uses a deliberately broken required MCP server to distinguish the cases. In user configuration, the broken server causes initialization failure. Moved into untrusted project configuration, it is disabled even with workspace-write access. Explicit trust makes the server load, revealing the initialization failure again.

That is a useful troubleshooting sequence, although the test is not a production repair recipe. First establish whether the configuration was loaded. Only then investigate whether the server starts, authenticates and provides the expected tools. Fixing the second layer cannot help if the first layer intentionally excluded the server.

The same test checks that trust survives an ephemeral run, that explicitly untrusted projects are refused, and that combining --trust with --ignore-user-config fails. Ignoring user configuration is therefore not an escape hatch for a stored trust decision.

A safer check for scheduled jobs

Before changing a scheduled review, record its working directory, Codex version, effective configuration location and exact startup warning. Compare those with the interactive environment that works. A different checkout path or configuration source can explain the mismatch without requiring broader tool permissions.

After an authorized trust decision, run a small read-only task and verify that the intended MCP server is available. Keep external writes disabled during diagnosis. If the server now fails to initialize, preserve that error and investigate its executable or authentication separately rather than assuming trust was not saved.

For shared runners, document who can approve project configuration and how that decision persists between jobs. An ephemeral conversation and an ephemeral security decision are different things. The important outcome is not simply restoring a missing tool; it is knowing why that repository is allowed to supply it.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help developer-tool teams explain configuration changes and security boundaries in practical technical guides.

Book a 30-minute call.