Legacy openai-curated plugins are reported enabled while the remote catalog suppresses them

Start with codex-rs/core-plugins/src/loader.rs around the suppression introduced by PR #29765, then trace the plugin inventory path used by codex plugin list --json and the capability paths exercised by codex debug prompt-input and app-server skills/list. Done means legacy openai-curated entries accurately expose their effective or suppressed state, with an explanation or migration status, while runtime loading and inventory agree.

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

Not applicable. The issue reproduces without a model response.

What platform is your computer?

Darwin 24.6.0 arm64 arm

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

Not terminal-specific. Reproduced through non-interactive CLI and app-server calls.

What issue are you seeing?

With ChatGPT authentication and the remote plugin catalog enabled, codex plugin list --json reports legacy @openai-curated plugins as both installed and enabled, even though Codex suppresses all of their skills, MCP servers, apps, and hooks.

Affected plugins in this reproduction:

build-ios-apps@openai-curated       9 skills
build-macos-apps@openai-curated    11 skills
remotion@openai-curated             1 skill
codex-security@openai-curated      12 skills

All 33 SKILL.md files exist and are loadable, but none appear in codex debug prompt-input.

App-server skills/list with forceReload: true also exposes 0/33 skills with no errors. Supplying the same directories through skills/extraRoots/set makes all 33 appear immediately.

The plugin inventory therefore reports these plugins as enabled while the effective runtime silently excludes them. No suppressed status, explanation, or migration path is provided.

What steps can reproduce the bug?

1. Authenticate Codex through ChatGPT.
2. Enable the remote plugin catalog and configure at least one legacy @openai-curated plugin:

[features]
remote_plugin = true

[plugins."build-ios-apps@openai-curated"]
enabled = true

3. Check its reported state:

codex plugin list --json |
  jq '.installed[] |
    select(.marketplaceName == "openai-curated") |
    {pluginId, installed, enabled}'

The plugin is reported with "installed": true and "enabled": true.

4. Check the effective skills:

codex debug prompt-input probe |
  rg 'build-ios-apps:|build-macos-apps:|remotion:|codex-security:'

Observed result: no matches.

What is the expected behavior?

If suppressing legacy openai-curated plugins is intentional, Codex should:

1. Report that the plugin is ineffective or suppressed and explain why.
2. Provide a migration path when a remote counterpart exists.
3. Explicitly report when no remote counterpart is available.
4. Ensure plugin inventory and runtime capability loading do not silently disagree.

For example:

{
  "installed": true,
  "enabled": true,
  "effective": false,
  "suppressedReason": "remote_catalog_active"
}

This report is not requesting that the suppression policy be reversed. It is requesting accurate effective status and a migration or explanation.

Additional information

PR #29765 introduced this suppression:

Current main still removes configured openai-curated plugins before loading their capabilities:

https://github.com/openai/codex/blob/bb1af235ea2822d7a40f75ef52e4d6a2cde84da2/codex-rs/core-plugins/src/loader.rs#L231-L243

p.s. I would love to fix the issue, if invited to open a PR