›_ Codex Issues
Codex Issues / #37801

Feature request: Make @ mentions extensible for integrations

Open 💬 1 comment Opened Aug 10, 2026 by cxliantgroup-creator

What variant of Codex are you using?

CLI, Codex App, and IDE Extension

What feature would you like to see?

Please make the @ mention system extensible so integrations can contribute their own mentionable resources to Codex.

Codex already provides @ mentions for native resources. Integrations should have a supported way to make external resources discoverable and selectable through the same experience, including resources that may change while Codex is running.

At a product level:

  • Integration-provided resources can appear in @ suggestions alongside native resources.
  • Users can search for and select those resources using the standard mention experience.
  • The selected resource keeps its identity and can be handled by the contributing integration when the prompt is submitted.
  • Integrations can update their available resources without requiring changes to Codex itself.
  • An unavailable integration does not break native @ behavior.

This request is intentionally implementation-neutral. It is not tied to a particular integration, resource type, transport, protocol, or Codex surface. The goal is a supported extension point so @ mentions can be extended without forking Codex or intercepting terminal input.

Additional information

Examples of mentionable resources could include repositories, documents, issues, services, people, agents, environments, or other objects from external tools. The exact extension mechanism should follow Codex's architecture.

View original on GitHub ↗

1 Comment

jdcodes1 · 9 days ago

Mapping this onto existing machinery, since most of the pieces have homes already:

  • The mention popup is mentions_v2 in the TUI with a typed candidate model — currently only MentionType::{Skill, File, Directory} (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/tui/src/bottom_pane/mentions_v2/candidate.rs#L19-L45) plus a search_catalog/search_mode pipeline that already handles async, filterable sources. Adding a kind backed by an external provider is an extension of that catalog rather than new UI.
  • MCP already defines the right wire concept for "integration-provided, changes while running": resources (resources/list + resources/updated notifications). Codex's MCP client tracks server resources today (the /mcp view lists them — tui/src/history_cell/mcp.rs), so the shortest path to this feature is: surface connected servers' resources as @-mention candidates, insert a reference the turn context resolves via resources/read at submit time. That gives repositories/documents/issues/people for free to any server that exposes them, with zero codex-specific plugin API.
  • Related asks worth designing together: #38215 wants configured agents mentionable (same candidate-kind extension), and #37903 wants plugin servers to know the workspace — the resolution step here has the same context-passing question.

The main open design question is trust/provenance: mention candidates from an external server are untrusted text entering the prompt at user-selection time, so labeling the source in the popup (and in the inserted reference) matters more here than for local files.