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

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

Redacted diagnostic summary. Project and Codex-home paths are placeholders

config/read: cwd=<project>, includeLayers=true
Project layer: <project>\.codex\config.toml
disabledReason: To load project-local config, hooks, and exec policies, add <normalized-project-path> as a trusted project in <CODEX_HOME>\config.toml.

Untrusted isolated control:
  Project layer disabled
  Obsidian absent from effective MCP configuration

Trusted isolated control:
  Project layer enabled
  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