Plugin-contributed skills are missing from the / autocomplete in attached sessions: session.skills.list returns zero plugin-sourced skills while the global list returns 35

[devinj-msft]

Affected version or release

Copilot app (github.exe) 1.1.15 · bundled CLI binary in ...\github-copilot-sdk\cli\1.0.83-5\, --version reports 1.0.84-1 · Windows 11 Enterprise 10.0.26200

Installation context

Local desktop install, single user. Three plugins installed: one from a GitHub-source marketplace (workiq@work-iq), two installed as local-path copies. All enabled. Their skills are discovered correctly at the app level.

What happened?

Plugin-contributed skills are missing from the / slash-command autocomplete in an attached session, while every other skill source (project, personal, custom, builtin) appears normally.

The app exposes two different skill lists, and they disagree:

API	Total skills	Plugin-sourced
skills.discover (global, app-level)	57	35 ✅
session.skills.list (attached session)	25	0 ❌

The session-scoped list returns project (1) + personal (14) + custom (8) + builtin (2) = 25, and zero plugin-sourced skills. Related: session.plugins.list for the same session returns only the built-in computer-use — none of the three installed plugins.

The skills themselves load and run correctly. Invoking one by its bare name works:

skill("quick-answer")   →  loads and executes successfully

So this is purely a session-scoped listing problem, not a loading problem.

Three observations that pin the mechanism precisely:

1. Immediately after app restart, before a session finishes attaching, plugin skills DO appear in the / menu. As soon as the session finishes resuming, they disappear. The menu evidently switches from the global list to the session list once the session attaches.

2. Typing a leading space makes them reappear. /quick-answer (space first) autocompletes; /quick-answer at position 0 does not. The leading-space path routes to a different menu that reads the global list.

3. A marketplace-installed plugin behaves identically. workiq is installed from a GitHub-source marketplace and has a bare commandName (workiq, no namespace prefix). At startup its skill appears; after resume it disappears like all the others. Only its MCP server entry (session.mcp.list → {"name": "workiq", "source": "plugin", "status": "needs-auth"}) remains in the menu — which is a different entity that happens to share the name. So the defect is not specific to the install route.

A secondary inconsistency, possibly the same root cause. For plugin skills installed as local-path copies, skills.discover reports a namespaced commandName that the skill runtime rejects:

{ "name": "quick-answer", "commandName": "engineering-plugin:quick-answer",
  "source": "plugin", "userInvocable": true, "enabled": true }

skill("engineering-plugin:quick-answer")  →  Skill not found: engineering-plugin:quick-answer
skill("quick-answer")                     →  loads successfully

The "not found" error lists every available skill by bare name only — no namespaced form exists in the registry. Non-plugin skills always have commandName == name, so they are unaffected.

Steps to reproduce

1. Install any plugin that contributes at least one skill (either copilot plugin install ./my-plugin or plugin@marketplace — both reproduce).
2. Restart the app and open a session that has previously been used, so it must resume.
3. Immediately, before the session finishes attaching, type / and the start of the skill's name — the plugin skill appears in the menu.
4. Wait for "Resuming session" to complete, then type the same thing at the start of an empty prompt — the plugin skill is now absent.
5. Type a space and then / and the same prefix — the plugin skill appears again.
6. Optionally, query session.skills.list for that session and compare with the global skills.discover; the former contains no entries with "source": "plugin".

Expected behavior

Plugin-contributed skills that are enabled and userInvocable should appear in the / autocomplete of an attached session, exactly as project, personal, custom and builtin skills do. The session-scoped skill list should include plugin-sourced skills rather than dropping them.

Additionally, commandName as reported by skills.discover should be a value the skill runtime actually accepts.

Additional context

Impact. Every plugin-contributed skill is undiscoverable through normal autocomplete once a session attaches. In my case that is 35 skills across three plugins. Because the skills still execute when typed in full, the failure looks like the skills are missing or broken rather than like a menu-population problem. The / menu is the primary way users discover available skills.

Workarounds. Type a leading space before /, or type the full bare skill name without relying on autocomplete.

Suspected cause. The session extensibility snapshot appears not to include plugin-contributed skills. session.plugins.list returning only computer-use, while the CLI's own session log reports Plugin activation [agents]: plugins=4, loaded=7 for that same session, suggests the app's session-scoped view of plugins is populated differently from the engine's — and that plugin skills are dropped when that view is built.

The corresponding per-session log line shows the app itself believes the session should have no skills:

extensibility live-session refresh completed session_id=<id>
  plugins_stale=false mcp_stale=false skills_stale=true
  observed_session_plugins=0 target_session_plugins=0
  target_session_skills=0

target_session_skills=0 and target_session_plugins=0 are present for every session, including sessions created long before any of my recent configuration changes.

Hypotheses I tested and ruled out, in case they save triage time:

• Filename case. Plugin skills in my two local plugins use skill.md; working skills use SKILL.md. Renaming one to SKILL.md changed nothing — and workiq uses SKILL.md and still disappears.
• Duplicate registration. Both plugins were registered twice (installed copy + a disabled live directory-marketplace entry). Removing the marketplace entirely and restarting changed nothing.
• Install route / namespacing. workiq is marketplace-installed with a bare commandName and still disappears after resume, so neither the install route nor the namespaced commandName explains the menu behavior.

Possibly related

• github/app#3550 — plugin-sourced agents receive no filename fallback for name/displayName. Same general area (plugin-contributed content mishandled by the app layer), different surface.
• github/app#3551 — live directory-marketplace plugins invisible to the app's global agent lookup and to session resume.
• github/app#2442 — request for a way to reload skills/custom agents without restarting; relevant because there is currently no way to refresh a session's skill list.

_{Paths, plugin names, skill names and session IDs in this report are genericized where they were specific to my setup; the reproduction does not depend on the originals.}

[devinj-msft]

Cross-references for triage:

• Plugin-sourced custom agents get no filename fallback for name/displayName, so they render as blank rows in the agent picker #3550 — plugin-sourced agents receive no filename fallback for name/displayName, so they render as blank rows in the agent picker.
• Live (directory-marketplace) plugins are invisible to the app's global agent lookup and to session resume, while the CLI resolves them correctly #3551 — live directory-marketplace plugins are invisible to the app's global agent lookup and to session resume. The session-scoped findings in this report may share a mechanism with Issue 2 of that report; see this comment.

All three are cases of plugin-contributed content being mishandled by the app layer while the CLI/engine resolves it correctly.

[devinj-msft]

Correction from the reporter: this is worse than I described. It is not only a listing problem — plugin skills fail to LOAD in app sessions.

In the original report I wrote:

The skills themselves load and run correctly. Invoking one by its bare name works: skill("quick-answer") → loads and executes successfully. So this is purely a session-scoped listing problem, not a loading problem.

That conclusion was based on an invalid test. I verified skill loading by running the CLI directly (copilot --agent <agent> --available-tools=skill -p "..."), which resolves skills from a registry that does include plugin-contributed skills. App sessions do not use that registry — they use the session-scoped one, which contains zero plugin skills. So the test never exercised the broken path.

In an app session, invoking a plugin skill fails outright. Invoking /wb-hub in an attached app session produces:

Failed to load skill wb-hub

Querying session.skills.list for that same session while it was running confirms why:

count=25  bysource={'project': 1, 'personal-copilot': 14, 'custom': 8, 'builtin': 2}
wb-hub present? False

The skill is absent from the session's registry, so the skill tool cannot resolve it. The agent then improvised, attempting to read the skill file from a guessed path that does not exist on disk (...\installed-plugins\<marketplace-name>\<plugin>\skills\... — the real location is under installed-plugins\_direct\<plugin>\), before falling back to searching the filesystem.

Corrected impact. Plugin-contributed skills are not merely undiscoverable in the / menu — they are unusable in app sessions entirely, whether typed in full, selected from the menu, or invoked by the agent itself. In my case that is 35 skills across three plugins. They continue to work correctly in CLI sessions, which is consistent with this being an app-layer defect in how the session extensibility snapshot is built.

Corrected workarounds. The leading-space trick I mentioned only restores the menu entry (which is drawn from the global list); it does not make invocation succeed, because invocation goes through the session registry. I am not aware of a working in-app workaround. Running the skill from the CLI (copilot --agent <agent> -p "...") does work.

Apologies for the imprecision in the original report — the severity should be read as "plugin skills are unusable in the app", not "plugin skills are hard to find".

[devinj-msft]

Update: the session skill registry is populated correctly at first, then plugin skills are dropped. This is a reconciliation regression, not a discovery failure.

Earlier I reported that session.skills.list never contains plugin-sourced skills. That is not quite right, and the corrected version is more diagnostic.

Immediately after an app restart, querying session.skills.list for a session returns the full, correct set:

total=61  bysource={'project':1, 'personal-copilot':15, 'plugin':35, 'custom':8, 'builtin':2}

All 35 plugin skills are present. Seconds later, querying the same session again returns:

total=26  bysource={'project':1, 'personal-copilot':15, 'custom':8, 'builtin':2}   plugin=0

Six consecutive samples at 3-second intervals after that point all returned total=26, plugin=0. So the plugin skills are discovered and registered into the session, and are then removed from it — they are not merely missing from the start. This matches the user-visible behavior exactly: plugin skills appear in the / menu immediately after restart and disappear the moment the session finishes resuming.

The corresponding refresh log line shows the app's target state contains no plugins at all:

extensibility live-session refresh completed session_id=<id>
  skills_stale=true observed_session_plugins=0 target_session_plugins=0 target_session_skills=0

observed=0, target=0 for plugins, while the CLI's own session log for the same session reports Plugin activation [agents]: plugins=4, loaded=7. The reconciliation step appears to compute a target set that omits plugin-contributed content and then prunes the session down to it, discarding the plugin skills that were correctly loaded moments earlier.

A workaround that does work, for anyone blocked on this: copying a plugin's skill directory into ~/.copilot/skills/<name>/ makes it register as source: personal-copilot, and personal skills survive the reconciliation. Verified end-to-end — the copied skill autocompletes and loads in an attached session while the identical plugin-sourced original fails in the same session. Note the file must be named SKILL.md; a lowercase skill.md (which is what my plugins use, and which the plugin loader accepts) is silently ignored by the personal-skill loader. That case-sensitivity difference between the two loaders may be worth a separate look.