Why does a Codex CLI MCP server appear in another repository?

Disclosure: This article was prepared with AI assistance. The two-repository scenario and configuration changes below are hypothetical and untested. They describe a diagnostic approach, not a reported repair. Official documentation checked on October 16, 2026.

Suppose you use a documentation MCP server in repo-a. You start Codex CLI in repo-b, where you do not need it, and the server still appears. Before reinstalling anything, check where that configuration lives.

Start with configuration scope

Codex can load personal settings from ~/.codex/config.toml and project overrides from .codex/config.toml. Project layers load only for trusted projects. Within a repository, configuration nearer the current working directory takes precedence over higher project directories; command-line overrides take precedence over project configuration. See Config basics.

A user-level MCP entry is therefore a plausible explanation for a server appearing across repositories. That is a hypothesis to verify against the actual launch command and configuration sources.

For example, the official documentation MCP setup supports this user-level entry:

[mcp_servers.openaiDeveloperDocs]
url = "https://developers.openai.com/mcp"

A small troubleshooting checklist

1. Record the CLI version, working directory, and exact launch command. Check aliases or wrappers for configuration overrides.
2. Locate the server definition. Inspect relevant user and project settings, selected profiles, and managed configuration. Redact tokens, headers, private paths, and URL parameters before sharing excerpts.
3. Check project trust. An ignored project override can explain unexpected behavior. Review an unfamiliar repository before trusting it merely to activate configuration.
4. Separate configuration from runtime status. codex mcp list shows configured servers; /mcp inside the CLI’s interactive interface shows active servers. These answer different questions. The MCP documentation explains both.
5. Check whether a plugin supplies the capability. Plugin-provided MCP servers use their own configuration namespace; a similarly named tool may have another source.

Before starting test sessions, inspect configured commands and endpoints. Startup can launch local MCP processes or contact remote services.

A hypothetical project override

If the server should remain available globally except in repo-b, a candidate change in repo-b/.codex/config.toml is:

[mcp_servers.openaiDeveloperDocs]
enabled = false

The MCP configuration reference documents enabled = false as a way to disable a server while retaining its definition.

Merge this into an existing table rather than appending a duplicate. Save the original diff first. The expected result depends on the installed version, project configuration loading, and higher-priority overrides. This example has not been executed.

Verify both repositories

Establish a baseline, then start fresh sessions in both repositories using the same version and launch method. Check that the target server is inactive in B and that A retains its baseline behavior. A disabled entry remaining in a configuration listing does not establish an active connection.

For rollback, reverse only this change and repeat the checks. Preserve unrelated edits made meanwhile.

Finally, hiding or disabling a capability does not demonstrate repository isolation or revoke server-side permissions. File access, network access, credentials, and remote authorization need separate review. Codex’s sandbox documentation describes technical boundaries and approval controls. A clean tool list alone cannot establish those boundaries.