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

Open 💬 1 comment Opened Jul 25, 2026 by naoto256
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.
  1. Confirm that it is enabled:

``bash
codex plugin list
``

Example output:

``text
example-plugin@example-marketplace installed, enabled
``

  1. Try to disable the plugin for one invocation:

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

  1. Observe that it is still reported as enabled:

``text
example-plugin@example-marketplace installed, enabled
``

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

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

  1. 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.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33995

Powered by Codex Action