Codex Desktop: @ tool/plugin picker is very slow with many installed tools and plugins

Summary

In Codex Desktop, typing @ in the chat composer to open the tool/plugin picker can take a very long time before suggestions are usable when the account/workspace has many available tools, plugins, connectors, skills, and MCP metadata.

This makes the @ affordance impractical in larger setups. Plain-language requests such as "use Telegram", "use the browser", or "use GitHub" are often faster because the agent can discover/load the relevant tool path without forcing the user through the full picker UI.

Environment

• Product: Codex Desktop
• App bundle: com.openai.codex
• Version observed: 26.623.101652
• Bundle version observed: 4674
• Platform: macOS, Apple Silicon
• Date observed: 2026-07-04
• Context: workspace/account with many installed and discoverable capabilities, including GitHub, Google apps, Firecrawl, Data Analytics, Computer Use, browser tools, local skills, and several MCP-backed tools.

Steps to reproduce

1. Use Codex Desktop in an environment with many installed plugins/connectors/tools/skills.
2. Focus the chat composer.
3. Type @ to open the tool/plugin picker.
4. Wait for suggestions to load and become usable.

Expected behavior

The picker should open quickly, ideally showing recent/frequent tools immediately and lazily loading the rest. Typing after @ should narrow results without waiting on full plugin/tool metadata enumeration.

Actual behavior

The picker takes ages to load in a tool-rich setup, making it feel blocked or unusable. The user experience is bad enough that the practical workaround is to avoid the picker entirely and ask in natural language for the desired tool.

Impact

This slows down daily Codex Desktop workflows and discourages use of the tool/plugin picker precisely for users who have invested in a richer connector/plugin setup.

It also increases cognitive friction: users need to remember natural-language tool names or rely on the agent to discover tools, instead of using the discoverable @ UI.

Suggested fixes

• Render a small initial list immediately: recent tools, pinned tools, or common tools.
• Cache plugin/tool metadata between picker openings and app sessions.
• Defer heavy descriptions, full manifests, or MCP metadata until the user searches or selects a candidate.
• Treat initial @ open as a fast UI path, with optional/slow plugins loaded in the background.
• Add instrumentation for picker-open latency, candidate count, plugin/tool metadata load time, and cache hit/miss.
• Consider separate sections for local skills, installed apps/connectors, MCP tools, and recently used entries so the UI does not need to rank the entire universe up front.

Related observations

This seems related to the broader class of startup/tool discovery latency issues, but it is a narrower interactive UI problem: the composer should remain responsive and the picker should show useful first results even if full tool discovery is expensive.

No logs or private workspace details are attached here. This report intentionally avoids including user paths, secrets, account identifiers, or connector payloads.

Feedback-id: 019f2d30-bb6b-78a3-81e1-c804f441ea8c