Codex Desktop ignores project .codex/config.toml MCP server (Serena) and only loads ~/.codex/config.toml

the same

@Primo83 please upvote the issue, this helps with visibility (this is how OpenAI prioritizes issues).

@Primo83 please upvote the issue, this helps with visibility (this is how OpenAI prioritizes issues).

“Hi! When you say ‘upvote the issue’, do you mean clicking the 👍 reaction on the issue?”

@Primo83 yes

@PaulRBerg, are other config settings in your project-scoped config file being honored, or is this specific to the MCP configuration? Are you sure this is a trusted project? As you know (from your bug report), Codex does not load project-scoped configs for untrusted projects.

@etraut-openai I am running Codex with:

sandbox_mode = "danger-full-access"

So I don't think I am ever prompted about trusted/untrusted projects. I don't remember being asked that recently when I use Codex in a new directory.

are other config settings in your project-scoped config file being honored

the MCP was the only thing in my local config. I will test later and let you know

I can reproduce something very similar on Windows 11.

Using clangd-mcp (tool-only MCP):

• User-level MCP config works in Codex CLI, Codex Desktop, and the Codex Cursor extension.
• Project-level MCP config works in Codex CLI only.
• The same project-level MCP does not appear in Codex Desktop or the Codex Cursor extension for the same workspace.

So this may be broader than Desktop alone: project-scoped MCP appears to be recognized by CLI, but not by Desktop / Cursor extension.

I discovered that using an absolute path to the project in the cwd parameter of the project’s .codex/config.toml makes Codex Desktop work with the MCP server. When collaborating, however, everyone has different absolute paths on their machines. Is there a way to work around this?

the same

Same here. I confirmed that it's probably similar on Codex Desktop on Windows 11 as well.

Environment:

• Codex Desktop version: 26.325.3894.0

The project is already marked as trusted in ~/.codex/config.toml, and the MCP server is defined only in the project's .codex/config.toml.

Expected behavior:
Codex Desktop should load the project-local MCP server definition for a trusted project.

Actual behavior:
Codex Desktop does not register the server from the project-local config. The server remains unavailable (unknown MCP server / not registered).

Workaround:
If I move the exact same MCP server definition into ~/.codex/config.toml and restart Codex Desktop, it is detected and works normally.

This suggests the problem is with project-scoped MCP config not being applied in Codex Desktop, rather than with a specific server definition.

I fight an hour and then gave up. Finally know whats the issue. I use Windows 11 Pro. really nasty bug! ⚡🤬☠️

please sort this out, it's super annoying

It’s pretty annoying and open bug like this is undermining your ypur credibility. You should focus on own product not producing plugin to Claude Code !!!

I'm also having this issue. When moving the config out to ~/.codex/config.toml it works fine.

Same here, please prioritize.

I'm wondering why there's been no response here. The documented behavior doesn't seem to be working as expected.

Same, here

I added a small packaged demo for the project/user config-scope evidence pattern in trace-to-skill@0.1.64:

npx trace-to-skill@0.1.64 demo mcp-discovery-mismatch
npx trace-to-skill@0.1.64 codex-report ./runs --output openai-codex-mcp-discovery.md

It is not a fix. It is meant to help people attach consistent evidence for this exact kind of report: app/CLI/Desktop/extension version, OS/IDE/remote or WSL state, workspace root, effective CODEX_HOME, user-global versus project .codex/config.toml, redacted MCP section, trust/profile/default-permissions state, codex mcp list, codex mcp get <server>, CLI-versus-Desktop comparison, loaded config path/log lines, whether moving the same server to ~/.codex/config.toml fixes it, and restart/reload/new-conversation behavior.

Release: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.64

Reproduced on Codex Desktop 26.707.72221, macOS 26.5.2 arm64.

This is a project-scoped MCP configuration case and appears to overlap both this issue and #24168.

Bounded reproduction

1. Started from an exact-clean Codex-managed worktree at the accepted current main commit (empty tracked/index/untracked diff).
2. Confirmed the committed project-local .codex/config.toml was present in that worktree.
3. The project config declares one repo-local stdio MCP server, enables a named tool, and sets that tool's approval_mode = "auto".
4. Restarted Codex Desktop and created a fresh task/worktree.
5. Inspected the fresh task's runtime tool inventory before any repository mutation.

Observed

• The expected project-local MCP namespace was absent.
• Runtime inventory result: BROKER_TOOL_MATCHES=0.
• The enabled tool could not be called because it was not injected/exposed to the task.
• Server calls: 0; repo writes: 0; runtime Allow prompts: 0.
• A stale-local-branch condition affected earlier attempts, but it was eliminated in this reproduction and is not causal.
• Task ID for maintainers: 019f6692-fe87-76c0-b59d-9a6ec4d6ce26.

Expected

For a trusted project, Codex Desktop should load the committed project-scoped MCP entry and inject its enabled tools into the fresh task, consistent with the documented project .codex/config.toml behavior.

Moving this server into global ~/.codex/config.toml is not an acceptable workaround for this case: it launches repository-local code from cwd = ".", so project-scoped trust is the intended security boundary.

This looks especially close to the missing session_meta.dynamic_tools behavior reported in #24168.

I observed a related variant on Windows Desktop after a reboot/reconnect. This may help distinguish a configuration-discovery failure from a stale MCP attachment.

Both the user-level and project-level Codex configuration resolved to a Serena command that included --context=codex and a project selection. codex mcp get serena also displayed that effective configuration.

However, the live Serena process used by the Desktop task had the command line:

serena start-mcp-server

It had no project or context arguments, exposed only the generic/default tool set, and did not expose the expected C# / LSP tools. Starting Serena manually with the configured context and project initialized the correct project and the LSP backend.

After terminating only that stale Serena process tree, Codex did not re-create it automatically. This left the task without Serena until an application-level reconnection/restart.

Expected behavior: a fresh Desktop task should start the MCP server from the effective configuration, retain the configured arguments in its process invocation, and provide a supported way to reload or reconnect the MCP attachment when that invocation is stale. This report does not claim that Serena ignored its arguments; the observed process simply was not given them by the host.

Desktop still loads user-level MCP config and ignores a project .codex/config.toml.

Method:

1. Copy the [mcp_servers.<name>] block into ~/.codex/config.toml.
2. Restart Desktop and start a new thread in that project. Old threads can keep a stale MCP process.
3. Confirm with codex mcp list / codex mcp get <name>.
4. If the tools look generic, kill the leftover MCP server process and start a fresh Desktop task so it relaunches with the user-level args.

Evidence: multiple Desktop reproductions; codex mcp list only shows user-level servers. A Windows variant also showed a live Serena process started without the configured --context / project args until that stale process was killed.

Independent community workaround; not an official OpenAI fix.