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
-
Install and enable a plugin that provides an MCP server.
-
Confirm that it is enabled:
Example output:
example-plugin@example-marketplace installed, enabled
-
Try to disable the plugin for one invocation:
codex \
-c 'plugins."example-plugin@example-marketplace".enabled=false' \
plugin list
-
Observe that it is still reported as enabled:
example-plugin@example-marketplace installed, enabled
-
Start a new Codex session with the same override:
codex \
-c 'plugins."example-plugin@example-marketplace".enabled=false'
-
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:
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.
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
-coverride 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: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
Install and enable a plugin that provides an MCP server.
Confirm that it is enabled:
Example output:
Try to disable the plugin for one invocation:
codex \ -c 'plugins."example-plugin@example-marketplace".enabled=false' \ plugin listObserve that it is still reported as enabled:
Start a new Codex session with the same override:
codex \ -c 'plugins."example-plugin@example-marketplace".enabled=false'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 listThe server remains 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 listThis correctly reports:
This indicates that the
-cargument 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:
The persistent value in
~/.codex/config.tomlshould 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
-coverride.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:
Persistently editing
~/.codex/config.tomlbefore and after every session is error-prone and prevents clean one-shot invocations.Related issues
enabled=falseThis report specifically concerns an installed plugin whose persisted user-level state is
enabled=true, while an explicit CLI-coverride attempts to disable it for one process.