recommended_plugins injection has no working opt-out (feature flag removed / disable-plugins is all-or-nothing)

Summary

The <recommended_plugins> block (list of ~38 not-installed third-party plugins, e.g. Atlassian, Airtable, HubSpot, ...) is unconditionally injected as an input_text item on the first user turn of every session, and there is no working client-side way to suppress it — even though a related feature-flag mechanism exists.

Environment

• codex-cli 0.146.0 (Windows, native CLI)
• Also reproduced earlier on 0.147.0-alpha.6.5

Steps to Reproduce (no API billing — uses local prompt rendering only)

codex debug prompt-input "test"

Output contains a developer/user message with:

"text": "<recommended_plugins>\nHere is a list of plugins that are available but not installed.\n\n- Airtable (airtable@openai-curated-remote)\n- Apollo.io (apollo@openai-curated-remote)\n...\n</recommended_plugins>"

~1,900 characters / ~470 tokens, listing ~38 plugins from a remote/hardcoded catalog (@openai-curated-remote) that is unrelated to the local codex plugin marketplace list configuration.

What I tried (all ineffective)

1. codex features list no longer even lists a recommended_plugins flag (it did on the alpha build tested earlier, shown as stable false). Running:

   codex debug prompt-input --disable recommended_plugins "test"
   

   now fails with Error: Unknown feature flag: recommended_plugins. On the earlier alpha build where the flag still existed, passing --disable recommended_plugins produced byte-identical output to the default run (only a random message ID differed) — i.e. the flag never actually controlled this injection path even when it was listed.

2. --disable plugins (the only remaining related flag, stable true by default) does remove the <recommended_plugins> block, but it does so by disabling the entire plugin instruction subsystem — it also strips the <plugins_instructions> block that documents currently-installed and enabled plugins. For a user with real plugins enabled (e.g. documents, spreadsheets, chrome, computer-use, pdf, ...), this is not usable: it silences the model's knowledge of plugins actually in use, not just the unused recommendations list.

3. Emptying the plugin marketplace config (-c "marketplaces={}", process-local, non-destructive) does not change the injected list at all — confirming the list is generated from a source independent of local [marketplaces] config.

Impact

Because history_mode: "legacy" resends full conversation history on every API call within a session, this ~470-token block is effectively billed on every turn of the session, not just the first — a constant, unavoidable per-session tax with no opt-out.

Expected behavior

Either:

• features.recommended_plugins (or an equivalent, currently-functional flag) actually gates this injection, independent of features.plugins, or
• the recommendation list is omitted/trimmed after the first turn (respecting history_mode), or
• there is a config key (e.g. show_recommended_plugins = false) to opt out without disabling real plugin functionality.

Additional notes

• Searched existing issues for recommended_plugins / "recommended plugin injection" and found no exact duplicate as of this report.
• Happy to provide the full codex debug prompt-input output (local rendering, no session/user data) if useful.

Start with codex debug prompt-input "test" and compare it with --disable plugins, the removed recommended_plugins flag, and an empty marketplace configuration. Trace the prompt-rendering and feature-flag entry points responsible for these blocks; done means recommendations can be disabled or limited without removing instructions for installed plugins, with the selected behavior reflected in the rendered prompt.