## Bug / enhancement ### Summary The `@` skill picker does not show a skill's package/plugin source, even when source metadata is available. This makes same-named skills difficult to distinguish. ### Reproduction 1. Install skills from more than one source, including a skill named `implement`. 2. Type `@` in a Codex conversation. 3. Search for `implement`. ### Actual behavior The picker shows only the bare skill name: ``` implement ``` ### Expected behavior Show the source/package along

Skill $ picker should display package/source provenance

Open 💬 1 comment Opened Aug 19, 2026 by donkw

Bug / enhancement

Summary

The @ skill picker does not show a skill's package/plugin source, even when source metadata is available. This makes same-named skills difficult to distinguish.

Reproduction

Install skills from more than one source, including a skill named implement.
Type @ in a Codex conversation.
Search for implement.

Actual behavior

The picker shows only the bare skill name:

implement

Expected behavior

Show the source/package alongside the name, for example:

implement · mattpocock-skills

or:

mattpocock-skills:implement

The local skill registry already has the provenance:

source: mattpocock/skills
plugin/package: mattpocock-skills
skill path: skills/engineering/implement/SKILL.md

The source metadata should remain optional for backward compatibility, but should be displayed whenever present.

Environment

Codex App on Windows
Skills installed through the local skill/plugin mechanism

View original on GitHub ↗

1 Comment

donkw · 9 days ago

Technical clarification

The current implementation already namespaces skills that are declared as Codex Plugin resources: plugin skills use the plugin_name:skill_name form (for example, sample:sample-search).

The gap is with skills installed by external skill installers into .agents/skills/. Their provenance is present in the installer's registry/lock metadata (for example, source: mattpocock/skills and pluginName: mattpocock-skills), but that metadata is not passed into Codex's host-skill discovery layer.

As a result:

plugin-provided duplicate names can be distinguished by their namespace;
standalone .agents/skills entries with the same name have no source-qualified display name in the @ picker.

Possible fix: preserve the existing names for compatibility, but expose optional provenance in the skill-list response and display it in the picker; when names collide, show a qualified form or otherwise make the source selectable.