Sign up
View stargazersSign up

[Bug]: Codex project MCP config is skipped without an actionable trust warning#15140

openedOct 3, 2026byNNeonsy

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Configure a working MCP server in a project’s .codex/config.toml with enabled = true. In my case this is an authenticated local HTTP Obsidian MCP server
  2. Use a Codex home whose user config.toml has no trusted-project entry for that project or a parent directory
  3. Open the project in T3 Code desktop, select the Codex provider, and start a chat in Full Access mode
  4. Ask the chat to use the project MCP server. Its tools are absent from the available tool catalog
  5. Inspect Codex app-server config/read with the actual project cwd and includeLayers: true. The project layer is found but disabled, with an explicit instruction to trust the project in the provider’s user config

The server endpoint was independently reachable and authenticated successfully, so the repro does not depend on the MCP service being down

Expected behavior

T3 should surface Codex’s project-layer disabledReason when project-local MCP configuration is skipped, including the affected project and the actual provider CODEX_HOME

Suggested remedy: Offer an explicit per-project “Trust this project for Codex” action or setting, with an explanation of what trusting the project enables. Full Access and Codex project trust are separate decisions. The action should update only the selected project’s trust in the Codex home used by that provider

After a trust or MCP config change, applying it must preserve other chats and running work. New provider sessions can pick up the change. Any refresh for the affected chat should preserve its conversation, wait for its running turn to finish, and avoid restarting a provider runtime shared with other chats

The reported failure is the missing actionable trust diagnostic. The trust action and scoped refresh are proposed remedies for that failure

Actual behavior

The chat cannot see the project’s Obsidian MCP tools, and I did not see a project-trust warning or a trust action explaining why the configured server was unavailable

Verified diagnostics:

  • The provider used the correct project working directory
  • Codex found the project .codex/config.toml, but config/read marked that layer disabled because the project was not trusted
  • The effective MCP configuration omitted the project server
  • The project server was enabled, with no enabled/disabled tool filters
  • Two isolated temporary CODEX_HOME controls used the same project config and differed in the project trust entry. The untrusted control omitted Obsidian. The trusted control loaded the project layer and mcpServerStatus/list authenticated successfully and discovered 52 tools
  • Built-in MCP servers were ready before the affected turn. This is a config-loading gate rather than evidence of a slow Obsidian startup
  • Restarting T3 did not remove the project-layer trust restriction

Related reports: #13437 concerns a partial catalog during MCP startup, #297 concerned the project working directory, and #9230 concerned unavailable env_vars. The verified cause in this reproduction is the untrusted project layer

Verification limit: The successful trust control was an isolated Codex app-server test. I have not trusted the real project config or verified a fresh T3 chat after enabling that trust

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261003.2623

Environment

Windows 10 Pro x64, build 19045 · T3 Code desktop nightly · Codex CLI 0.160.0 · Local authenticated HTTP Obsidian MCP

Logs or stack traces

shell
1Redacted diagnostic summary. Project and Codex-home paths are placeholders
2
3config/read: cwd=<project>, includeLayers=true
4Project layer: <project>\.codex\config.toml
5disabledReason: To load project-local config, hooks, and exec policies, add <normalized-project-path> as a trusted project in <CODEX_HOME>\config.toml.
6
7Untrusted isolated control:
8 Project layer disabled
9 Obsidian absent from effective MCP configuration
10
11Trusted isolated control:
12 Project layer enabled
13 mcpServerStatus/list: Obsidian authenticated, 52 tools discovered

Screenshots, recordings, or supporting files

No response

Workaround

In an isolated temporary Codex home, adding the matching project entry with trust_level = "trusted" enabled the project MCP server

A manual trust entry in the actual provider’s user config followed by a fresh provider session is the proposed workaround. It has not been applied or verified in my real T3 project

A provider-wide restart could affect other chats sharing that runtime, so it should not be required to apply a project trust change to one chat

JJulius MarmingeOct 3, 2026

Note

Grok responding on behalf of Julius.

Triage

Thanks @Neonsy for the thorough diagnosis, and especially the trusted and untrusted CODEX_HOME controls! This is a real gap on current main, including nightly 0.0.46-nightly.20261003.2623. Nothing since that nightly touches the Codex session path.

What happens

Codex loads a project .codex layer (MCP servers, hooks, and exec policies) only when that project is trusted in the Codex home's config.toml. Full Access doesn't grant that trust. In CodexAdapterV2, Full Access only starts the turn with approvalPolicy: "never" and sandboxPolicy: { type: "dangerFullAccess" }. Thread start passes the project cwd and session config overrides, which Codex layers above the user and project config.

T3 never calls config/read with includeLayers, and the adapter doesn't subscribe to configWarning. So when Codex disables the project layer, the MCP tools just go missing and the layer's disabledReason never reaches the chat. Codex's own TUI shows that reason by reading the project layer, and T3 doesn't. That matches your isolated controls: same project config, with and without trust_level = "trusted".

This is separate from #13437 (open; a partial tool catalog while MCP servers are still starting), #297 (closed; an MCP process whose working directory didn't match the project), and #9230 (closed; env_vars on desktop-launched profiles).

Scope

The bug is the missing diagnostic. A per-project "Trust this project" action would be a separate product change. Trusting a project also enables its hooks and exec policies, the entry has to use the exact project key from disabledReason, and the app-server schema T3 generates has no trust RPC. Copying the project's MCP servers into the session config would quietly bypass Codex's trust gate. A maintainer will decide on the fix direction.

Workaround

This matches your isolated control. In the config.toml of the Codex home named in disabledReason, add the project key Codex names, with trust_level = "trusted". Then start a new Codex session, because an already-open session won't pick up the project layer. You don't need to restart T3 for the file edit itself. On a shadow-home instance, config.toml is shared from the configured Codex home unless that shadow already has its own real file.

JJulius Marminge22d ago

Reproduced on Linux with Codex 0.163.0 and the web dev app at defb7e6e6b. An enabled local MCP fixture in an untrusted project's .codex/config.toml was absent from a Full Access chat's tool catalog, and the chat showed no trust diagnostic. config/read with that project's cwd returned the disabled project layer and the remedy naming the actual provider Codex home. An isolated trusted control loaded the same MCP configuration.

Full Access chat without a project-trust diagnostic