Filter plugin install suggestions by installed apps

[nm-openai]

Summary

• Keep the original TOOL_SUGGEST_DISCOVERABLE_PLUGIN_ALLOWLIST as a fallback seed list, so users with no installed plugins still get initial install suggestions.
• Allow additional install suggestions from trusted marketplaces: openai-curated and openai-bundled.
• Require non-fallback, non-configured marketplace candidates to share .app.json connector IDs with already installed plugins.
• Preserve explicit configured plugin discoverables as an override, while still omitting installed, disabled, and NOT_AVAILABLE plugins.

Context

list_available_plugins_to_install controls which plugins the model can trigger via request_plugin_install. We want a small starter set for empty/new users, but we also want installed workflow plugins to unlock relevant source plugins without maintaining every source plugin ID by hand.

This keeps the legacy plugin ID allowlist only as the starter fallback. For everything else, the trusted marketplace is the candidate boundary, and installed app connector overlap is the relevance filter. For example, an installed Sales plugin can make HubSpot and Granola suggestible when those source plugins are in openai-curated and share Sales app connector IDs, while an unrelated test-source plugin with an app connector not declared by Sales stays hidden.

Test Coverage

• Empty/no-installed-plugin case: returns the fallback seed plugins from the original allowlist.
• Installed-app expansion: returns non-fallback marketplace plugins only when their app connector IDs overlap with an installed plugin.
• Sales workflow case: installed Sales declares HubSpot and Granola apps, so hubspot@openai-curated and granola@openai-curated are returned.
• Sales negative case: test-source@openai-curated has an app connector not declared by Sales, so it is not returned.
• Existing guardrails: installed plugins, disabled suggestions, and NOT_AVAILABLE plugins remain omitted; explicit configured discoverables still work as an override.

Validation

• just fmt
• just test -p codex-core plugins::discoverable::tests
• just test -p codex-core was attempted earlier, but current main / local env failed with unrelated existing failures around missing test_stdio_server, CLI/code-mode MCP tool setup, and unified_exec/shell snapshot flakes/timeouts. The touched discoverable tests pass.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2131520cd6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Filter non-installable curated plugins

When an openai-curated marketplace entry has policy.installation = NOT_AVAILABLE, this new broad is_openai_curated branch still exposes it through list_available_plugins_to_install, but the actual install path rejects the same entry in find_installable_marketplace_plugin with PluginNotAvailable. In that marketplace-policy scenario the model can ask the user to install a plugin that will always fail after confirmation, so curated suggestions should still exclude non-installable policies before returning them.

Useful? React with 👍 / 👎.

[nm-openai]

Addressed in the latest push: list_tool_suggest_discoverable_plugins now filters out MarketplacePluginInstallPolicy::NotAvailable before returning candidates, and there is a regression test covering a NOT_AVAILABLE openai-curated plugin.

[nm-openai]

I have read the CLA Document and I hereby sign the CLA