OpenAI-curated plugin manifests are repeatedly validated during normal turn/subagent setup #19382

What version of Codex CLI is running?

codex-cli 0.124.0

What subscription do you have?

No response

Which model were you using?

gpt-5.5

What platform is your computer?

Linux

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

No response

What issue are you seeing?

Codex appears to repeatedly scan/validate manifests from the local openai-curated plugin marketplace cache during normal turn/subagent setup, even for plugins that are not enabled or installed by the user.

The visible symptom is repeated manifest warnings for cached marketplace plugins such as build-ios-apps and plugin-eval:

codex_core_plugins::manifest: ignoring interface.defaultPrompt: prompt must be at most 128 characters path=~/.codex/.tmp/plugins/plugins/build-ios-apps/.codex-plugin/plugin.json
codex_core_plugins::manifest: ignoring interface.defaultPrompt: maximum of 3 prompts is supported path=~/.codex/.tmp/plugins/plugins/plugin-eval/.codex-plugin/plugin.json

This looks related to, but distinct from, #19372. In this case the problematic manifests are from the local openai-curated marketplace cache, not an auto-mirrored Claude marketplace.

It also appears related to #17638, which merged a fix for repeated curated-marketplace loading in list_tool_suggest_discoverable_plugins(). The warning pattern from #17638 is still reproducible in another path on 0.124.0.

What steps can reproduce the bug?

1. Use Codex CLI 0.124.0 with the default/openai-curated plugin marketplace cache present under ~/.codex/.tmp/plugins.
2. Do not enable the affected plugins in ~/.codex/config.toml.
3. Start normal Codex work and/or spawn subagents.
4. Inspect ~/.codex/log/codex-tui.log.
5. Observe repeated manifest validation warnings for cached marketplace plugins that were not requested.

In my local config, the only explicitly configured MCP server is a remote open-brain server. The GitHub plugin had been enabled initially, then was changed to:

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

The repeated warnings still show that unrelated cached marketplace manifests are being parsed/validated during ordinary turn handling. Example timestamps from one run include repeated pairs from 14:41:39 through 14:46:24 UTC on 2026-04-24, across multiple session_loop thread IDs.

What is the expected behavior?

Codex should not repeatedly deep-validate every available marketplace plugin manifest during normal turn dispatch or subagent setup.

Preferably:

• Installed/enabled plugins are loaded during startup/session setup.
• Available marketplace plugins are indexed once, with validation results cached.
• Full manifest validation for unavailable/uninstalled plugins happens only when listing/searching/installing plugins, or when a plugin is explicitly referenced.
• Invalid manifests in available-but-unused plugins should not produce repeated warnings in ordinary session logs.

Additional information

Related findings:

• feat: Avoid reloading curated marketplaces for tool-suggest discovera… #17638 already addressed one repeated curated-marketplace loading path and included the same build-ios-apps interface.defaultPrompt warning pattern.
• Codex auto-mirrors Claude Code marketplaces, breaking MCP handshake for Claude-only plugins #19372 reports overly broad marketplace auto-discovery for Claude marketplaces.
• Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure #18333 reports repeated full MCP stacks for sessions/subagents; this issue is narrower and specifically about plugin manifest scanning/validation noise and possible setup overhead.

Local timing while investigating subagent startup:

• session_init.mcp_manager_init: about 3 ms
• session_init.auth_mcp: about 650-880 ms
• The full minimal subagent round trip was several seconds, with plugin manifest warnings appearing during the subagent turn setup.

This suggests actual MCP manager initialization was not the main cost in this setup, but the plugin/app/auth/setup path is doing more work than expected for plugins that were not used.