Remote curated plugins ignore per-plugin enabled=false config

[Michaelihc]

What version of Codex CLI is running?

codex-cli 0.140.0

What subscription do you have?

Not specified.

Which model were you using?

gpt-5.5

What platform is your computer?

Windows x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal, running PowerShell.

Codex doctor report

Codex Doctor v0.140.0 · windows-x86_64

Environment
  ✓ system       en-US
  ✓ runtime      standalone (windows, package <CODEX_HOME>\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc, bin <CODEX_HOME>\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\bin, resources <CODEX_HOME>\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\codex-resources, path <CODEX_HOME>\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\codex-path)
  ✓ install      consistent
  ✓ search       file exists (bundled)
  ✓ git          git version 2.54.0.windows.1
  ✓ terminal     Windows Terminal · zellij 0.44.3
  ✓ state        databases healthy
  ✓ threads      rollout files and state DB thread inventory agree

Configuration
  ✓ config       loaded
  ✓ auth         auth is configured
  ✓ mcp          1 server (1 stdio) · 0 disabled
  ✓ sandbox      restricted fs + restricted network · approval OnRequest

Updates
  ✓ updates      update configuration is locally consistent

Connectivity
  ✓ network      no proxy env vars
  ✓ websocket    connected (HTTP 101 Switching Protocols) · 15s timeout
  ✓ reachability active provider endpoints are reachable over HTTP

Background Server
  ○ app-server   not running (ephemeral mode)

17 ok · 1 idle · 0 warn · 0 fail ok

What issue are you seeing?

Per-plugin enabled = false entries in ~/.codex/config.toml do not suppress remote curated plugin injection in fresh Codex CLI sessions.

My config explicitly disables several remote curated plugins:

[plugins."data-analytics@openai-curated-remote"]
enabled = false

[plugins."figma@openai-curated-remote"]
enabled = false

[plugins."product-design@openai-curated-remote"]
enabled = false

[plugins."public-equity-investing@openai-curated-remote"]
enabled = false

Despite that, a fresh codex exec --ephemeral session still exposes those plugins in the model-visible plugin context:

browser
computer-use
data-analytics
documents
figma
github
pdf
presentations
product-design
public-equity-investing
spreadsheets

This is not stale context from an existing conversation. It reproduces in a new ephemeral CLI session after upgrading from 0.139.0 to 0.140.0.

codex plugin list does not show these remote curated plugins as locally installed/enabled through the regular CLI marketplace path. It only shows the primary runtime plugins as installed/enabled in this environment:

documents@openai-primary-runtime
pdf@openai-primary-runtime
spreadsheets@openai-primary-runtime
presentations@openai-primary-runtime

The remote curated plugin bundles are cached locally under a path like:

<CODEX_HOME>\plugins\cache\openai-curated-remote\

but the user-facing installed plugin list and the per-plugin disabled config do not reflect or control the injected session context.

What steps can reproduce the bug?

1. Use Codex CLI 0.140.0 on Windows with plugins enabled.

2. Add explicit disabled entries for remote curated plugins to ~/.codex/config.toml:

   [plugins."data-analytics@openai-curated-remote"]
   enabled = false
   
   [plugins."figma@openai-curated-remote"]
   enabled = false
   
   [plugins."product-design@openai-curated-remote"]
   enabled = false
   
   [plugins."public-equity-investing@openai-curated-remote"]
   enabled = false

3. Start a fresh ephemeral session:

   codex exec --ephemeral --skip-git-repo-check -C <empty-test-dir> "List the plugins directly visible/injected into this context. Do not run tools. Return only the plugin names, one per line."

4. Observe that the disabled remote curated plugins are still injected:

   data-analytics
   figma
   product-design
   public-equity-investing
   

5. As a control, disable all plugin/app surfaces plus the explicit node_repl MCP server:

   codex exec --ephemeral --skip-git-repo-check -C <empty-test-dir> `
     -c 'features.plugins=false' `
     -c 'features.apps=false' `
     -c 'mcp_servers.node_repl.enabled=false' `
     "List the plugins directly visible/injected into this context. Do not run tools. Return only the plugin names, one per line. If none are visible, return NONE."

6. Control output:

   NONE
   

What is the expected behavior?

If a plugin has this config:

[plugins."plugin-name@marketplace"]
enabled = false

then a fresh Codex session should not inject that plugin's skills/plugin instructions into the model-visible context.

If remote curated plugins are account-synced or controlled by a different identifier than plugin-name@openai-curated-remote, Codex should expose that state clearly in codex plugin list, codex doctor, and documentation, and provide a documented per-host/per-session way to disable each remote curated plugin without turning off all plugins.

Actual behavior

Per-plugin disabled entries appear to be ignored for openai-curated-remote plugin injection. The only reliable workaround found is feature-level disabling:

[features]
plugins = false
apps = false

[mcp_servers.node_repl]
enabled = false

That removes the unwanted remote curated plugin context, but it also disables all plugin/app functionality and is too broad for users who want primary runtime plugins or selected plugins enabled.

Additional information

Related/adjacent issues found before filing:

• Data Analytics plugin tools appear in remote Codex CLI without local install/config #26275: Data Analytics plugin tools appear in remote Codex CLI without local install/config.
• Failed to parse the request body as JSON: client_metadata.x-codex-installation-id: EOF while parsing a string #21520: Older report that skills/plugins set to enabled = false were still injected into the request body.

This report is narrower: it reproduces on codex-cli 0.140.0 with explicit per-plugin enabled = false entries for openai-curated-remote plugins, in fresh codex exec --ephemeral sessions.

[MakenRosa]

I traced this through the plugin loader and the report looks reproducible from the current code path.

What happens today:

• plugins_for_config_with_force_reload() builds the load cache key from only persisted user plugin config + skill rules + remote_plugin_enabled, then calls load_plugins_from_layer_stack(..., self.remote_installed_plugin_configs(), ..., config.remote_plugin_enabled).
• remote_installed_plugin_configs() converts the remote-installed cache into PluginConfig { enabled: plugin.enabled, ... } for every locally cached remote bundle.
• merge_configured_plugins_with_remote_installed() then merges those extra_plugins into user config.
• For local curated vs remote curated name conflicts, prefer_remote_curated_conflicts == config.remote_plugin_enabled, so when remote plugins are enabled, the remote linear@openai-curated-remote style entry intentionally replaces local curated entries with the same plugin name.
• There is no special case for a user-authored [plugins."foo@openai-curated-remote"] enabled = false; if the remote installed cache says enabled = true, the remote cache entry is inserted/overwritten during the extra-plugin merge.

Existing test coverage already demonstrates the conflict behavior:

cargo test -p codex-core-plugins remote_installed_cache_prefers_remote_curated_conflicts_when_remote_plugin_enabled --lib

This passes and asserts that with remote_plugin = true, a local linear@openai-curated entry is replaced by linear@openai-curated-remote.

I think the missing behavior is precedence for explicit user disablement. A narrow fix would be for merge_configured_plugins_with_remote_installed() to preserve an explicit configured entry for the same remote plugin key when that entry is enabled = false, or to overlay user config after remote-installed config specifically for enabled. The important part is that the remote-installed server state should be allowed to add installed plugins, but not silently re-enable a plugin the local config explicitly disabled.

This also explains the confusing codex plugin list angle: listing and execution appear to consult different surfaces. Execution sees self.remote_installed_plugin_configs() during plugins_for_config(), while the list UI can omit those remote installed plugins depending on visible marketplaces/configured state. So the plugin can be injected during exec even when it is not obvious from plugin list.