Skip to content

Regression - invoking /plugin-skill-name slash commands no longer work - client used to rewrite them to natural language, now fires a doomed session.commands.invoke RPC #2599

Description

@malcolms

Describe the bug

I'm using the copilot app rather than CLI directly, but I believe the issue is at the CLI level.

Invoking a plugin-provided skill as a slash command (e.g. /grill-me ) used to work by having the desktop app's client rewrite the input into a natural-language instruction before ever contacting the session backend. As of today (previously working yesterday, same plugin, same machine, no plugin content changes), the client instead sends the raw literal text as the prompt and separately fires an execute_session_command RPC, which the backend rejects with Unknown slash command: /.

This reproduces on a brand-new session, first message — ruling out session staleness, plugin reinstallation, or plugin content changes as the cause.

GitHub Copilot app / CLI 1.0.78-2 (Windows). Last known working: pre-1.0.78 (yesterday, 2026-08-03 morning).

Affected version

GitHub Copilot CLI 1.0.78-2

Steps to reproduce the behavior

  1. Install any plugin providing a skill intended for slash-command use (e.g. via a private/user-scope plugin marketplace), e.g. mattpocock-skills's grill-me, whose SKILL.md sets disable-model-invocation: true and whose whole body is Run a /grilling session. — i.e. it is designed to be invoked only via /grill-me, with no natural-language fallback.
  2. In a fresh session, type /grill-me <some text> as the very first message.
  3. Observe: Unknown slash command: /grill-me error, despite the skill being installed and enabled.

Note: this reproduces identically for skills with or without disable-model-invocation: true in their SKILL.md frontmatter — e.g. grilling (a normal model-invocable skill, no such flag) fails the exact same way as /grilling. That flag is not the differentiator; it only means a skill like grill-me has no natural-language fallback, so it's affected more severely (no workaround at all) rather than being the cause of the bug.

Expected behavior

  • The slash command should resolve and invoke the skill (preferred), or
  • If a hard RPC-based invocation isn't supported for plugin-sourced skills, the client should fall back to the natural-language rewrite it used to perform (as seen in the "before" evidence), rather than surfacing a hard error.

Additional context

Evidence — before (working, 2026-08-03 08:17:25)

Client-side log shows the typed /grill-me <args> was rewritten before being sent over the websocket:

kind="send_message" ... "prompt":"Use the skill tool to invoke the 'grill-me' skill, then follow the skill's instructions.\n\nAdditional context from the user:\n<user args>"

No execute_session_command RPC was ever issued for this invocation — it succeeded purely via the natural-language / skill-tool path.

Evidence — after (broken, 2026-08-04 09:36:45, fresh session)

kind="execute_session_command" text={"session_id":"<new-session-id>","command_name":"grill-me","args":"Does this work?"}
...
github_app::session::core: invoking session command session_id=<new-session-id> command_name="grill-me"
...
ERROR ... failed to invoke session command error=RPC error -32603: Request session.commands.invoke failed with message: Unknown slash command: /grill-me

This is the very first message of a brand-new session (create_worktree_workspace → kickoff), so it cannot be explained by stale session state, a stale plugin, or a config issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions