CLI -c override is ignored for installed plugin enabled state and plugin-provided MCP servers

Start at the CLI -c override handling and plugin configuration resolution, then compare it with the working mcp_servers override path. Reproduce with codex plugin list, mcp list, and a new session using the documented commands; done means plugin and plugin-provided MCP state honor temporary overrides without changing the persisted config.

What version of Codex CLI is running?

codex-cli 0.144.6

What platform are you using?

macOS

What issue are you seeing?

A command-line -c override cannot disable an installed plugin for a single Codex process or session.

Given an installed plugin that provides an MCP server and is enabled in ~/.codex/config.toml:

[plugins."example-plugin@example-marketplace"]
enabled = true

[plugins."example-plugin@example-marketplace".mcp_servers.example-mcp]
enabled = true

Starting Codex with the following override does not disable the plugin:

codex -c 'plugins."example-plugin@example-marketplace".enabled=false'

The plugin remains enabled, and its MCP server and tools are still exposed in the new session.

This reproduces with two installed plugins from different marketplace source types.

Steps to reproduce

1. Install and enable a plugin that provides an MCP server.

2. Confirm that it is enabled:

   codex plugin list
   

   Example output:

   example-plugin@example-marketplace  installed, enabled
   

3. Try to disable the plugin for one invocation:

   codex \
     -c 'plugins."example-plugin@example-marketplace".enabled=false' \
     plugin list
   

4. Observe that it is still reported as enabled:

   example-plugin@example-marketplace  installed, enabled
   

5. Start a new Codex session with the same override:

   codex \
     -c 'plugins."example-plugin@example-marketplace".enabled=false'
   

6. Observe that the plugin-provided MCP server and tools are still exposed and callable in the new session.

A more specific override for the plugin-provided MCP server is also ignored:

codex \
  -c 'plugins."example-plugin@example-marketplace".mcp_servers.example-mcp.enabled=false' \
  mcp list

The server remains enabled:

example-mcp  ...  enabled

Control case

The same CLI override mechanism works for an ordinary user-configured MCP server:

codex \
  -c 'mcp_servers.example-user-mcp.enabled=false' \
  mcp list

This correctly reports:

example-user-mcp  ...  disabled

This indicates that the -c argument and TOML dotted-path quoting are working. The issue appears specific to plugin configuration resolution.

Expected behavior

This command:

codex -c 'plugins."example-plugin@example-marketplace".enabled=false'

should disable that plugin for the current Codex process and any session started by it, including its:

• MCP servers and tools
• skills and instructions
• hooks

The persistent value in ~/.codex/config.toml should remain unchanged.

Likewise:

-c 'plugins."example-plugin@example-marketplace".mcp_servers.example-mcp.enabled=false'

should disable only the specified plugin-provided MCP server.

Actual behavior

The persisted user-level plugin state appears to take precedence over the CLI -c override.

Both the CLI status commands and the actual session tool surface continue to treat the plugin and its MCP server as enabled.

Why this matters

Per-process plugin overrides are useful for:

• least-privilege sessions
• isolating plugin or MCP failures
• reducing irrelevant tools and instructions
• launcher scripts and task-specific Codex profiles
• verifying behavior with and without a plugin

Persistently editing ~/.codex/config.toml before and after every session is error-prone and prevents clean one-shot invocations.

Related issues

• #28443 — remote curated plugins ignore per-plugin enabled=false
• #18115 — plugin enablement does not follow normal project/config layering
• #13076 — earlier CLI config override ordering issue for MCP configuration

This report specifically concerns an installed plugin whose persisted user-level state is enabled=true, while an explicit CLI -c override attempts to disable it for one process.