Plugin MCPs are disabled when plugin requirements contain no MCP allowlist

[publi0]

Summary

Plugin-provided MCP servers are all marked enabled = false when requirements.plugins is present but none of its entries declares mcp_servers.

A plugin requirement unrelated to MCP policy should not implicitly become an empty MCP allowlist. This can make plugin installation and codex mcp login succeed while new TUI, codex exec, and Desktop sessions receive none of the plugin MCP tools.

Root cause

In filter_plugin_mcp_servers_by_requirements() (codex-rs/core/src/config/mod.rs), the function returns early only when requirements.plugins is absent. When the plugins map exists but every PluginRequirementsToml::mcp_servers is None, allowed evaluates to false for every plugin MCP. Each server is disabled with McpServerDisabledReason::Requirements, so the connection manager never creates its client.

This is distinct from an explicit empty allowlist (mcp_servers = {}), which should continue to deny all plugin MCPs.

Minimal regression case

Construct requirements containing a plugin entry with mcp_servers: None, then pass an otherwise valid plugin MCP through filter_plugin_mcp_servers_by_requirements().

Expected: the MCP remains enabled because no MCP allowlist was declared.

Actual: the MCP is disabled with McpServerDisabledReason::Requirements.

Suggested fix

Skip MCP filtering unless at least one plugin requirement actually declares mcp_servers:

if !requirements
    .value
    .values()
    .any(|plugin| plugin.mcp_servers.is_some())
{
    return;
}

This preserves populated and explicitly empty allowlists while preventing unrelated plugin requirements from disabling every plugin MCP.

User-visible symptom

• Plugin inventory reports the plugin and MCP as installed/enabled.
• codex mcp login can complete successfully.
• A fresh runtime does not connect to or expose the plugin MCP tools.
• Desktop may display Auth unsupported, although the server was disabled by requirements before authentication.

Validation performed

Against Codex CLI 0.144.5 source:

• A focused regression test fails before the guard and passes after it.
• Existing explicit allowlist tests continue to pass.
• codex-cli builds successfully.
• In an isolated smoke test, the unpatched binary materializes the plugin MCP as disabled; the patched binary enables it and completes tools/list.

It would also help if the UI surfaced disabled_reason = Requirements instead of presenting this state as an authentication limitation.

[Kevinjohn]

Plugin MCPs are currently disabled when requirements.plugins exists but does not declare any MCP policy.

Confirmed against current main at 7844386e3d.

The problem is in filter_plugin_mcp_servers_by_requirements(): the presence of the plugins requirements map is treated as an MCP allowlist, even when every PluginRequirementsToml::mcp_servers value is None. That makes every plugin MCP fail the allowed check and assigns McpServerDisabledReason::Requirements.

I have a focused patch prepared:

• Return before filtering unless at least one plugin requirement actually declares mcp_servers.
• Keep mcp_servers = {} distinct: Some(empty) still counts as a declared allowlist and continues to deny all plugin MCPs.
• Add a regression test proving that mcp_servers: None leaves an otherwise enabled plugin MCP unchanged.

Actual screenshots

Before — the focused test shows the server incorrectly changed to false with a Requirements reason instead of remaining true with no disabled reason:

After — the same focused regression passes with the guard applied:

Validation:

• Focused regression: passes.
• All four filter_plugin_mcp_servers* tests: 4 passed.
• just fix -p codex-core: passes.
• just fmt: passes.

---

I have a PR ready if issue accepted

[ofekron]

The key distinction here is "no MCP policy declared" versus "declared empty MCP allowlist." Those need different states all the way through the plugin lifecycle.

I would model it as:

• plugin discovered bundled MCP servers;
• plugin requirements contain no MCP section, so MCP policy is not constrained by requirements;
• plugin requirements contain an explicit empty MCP allowlist, so bundled MCPs are denied;
• resolved effective grant is then what the runtime uses to attach servers and emit tools.

That also gives the UI a better explanation than an auth-looking failure. Users need to see "disabled by requirements" versus "auth unsupported" versus "server attached but tools not injected."

I maintain Better Agent (https://github.com/ofekron/better-agent), and the same desired/effective-state split is important for provider plugins and MCP capability grants. If this kind of agent-runtime debugging is useful, a star helps others find the project.