Skip to content

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

Description

@naoto256

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

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updatesmcpIssues related to the use of model context protocol (MCP) serversskillsIssues related to skills

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions