Skip to content

skill tool intermittently fails in headless -p mode: "No model-invocable skills available" #4838

Open

Description

@armannjo

Describe the bug

In headless ( copilot -p ... ) mode, the skill tool intermittently fails to resolve a skill that is simultaneously listed — with full name and description — in that same request's  <available_skills>  system-prompt block. The error is not "skill X not found among Y available skills" but the more absolute:

Skill "" not found. No model-invocable skills available.

This indicates the tool-call-time invocable-skill registry is empty even though prompt-construction-time skill discovery succeeded moments earlier in the same process. Failures are intermittent — the same skill succeeds on some invocations and fails on others — and once a failure occurs, subsequent headless invocations (different skills, 6–90s spacing, with/without  --available-tools=skill ) keep failing for an extended window (minutes to, in one earlier observation, ~2 days) before recovering. Interactive-mode invocations of the same skills, same environment, succeeded reliably throughout.

Not explained by skill symlink type (tested both relative and absolute symlink targets under  ~/.copilot/skills  — both fail identically once in a bad window), and the skill has no  disable-model-invocation / allow_implicit_invocation: false  policy set.

Prior art checked, not duplicates: #4438 and #4451 (skills excluded via  disable-model-invocation  policy — not applicable here), #4401 ( ~/.agents/skills  unsupported discovery path — our skills are under the supported  ~/.copilot/skills ).

Affected version

1.0.83

Steps to reproduce the behavior

  1. Install a user-level skill at  ~/.copilot/skills//SKILL.md  (supported path, no  disable-model-invocation  policy).
  2. Run:
    copilot -p "Use the skill tool to load the skill named and report the first 6 words of its description." --no-ask-user --log-level debug --log-dir /tmp/debug
  3. Repeat several times in quick succession (some spaced 6–90s apart).
  4. Inspect  /tmp/debug/process-*.log : the system prompt sent to the model correctly contains the skill under  <available_skills> , but the tool-call response for that same skill name is:
    Skill "" not found. No model-invocable skills available.

Expected behavior

The invocable-skill registry checked at tool-call time should stay consistent with the skill listing rendered into the system prompt for the same request — a correctly installed, policy-unrestricted, supported-path skill should not intermittently disappear from resolution.

Additional context

• OS: macOS (darwin-arm64)
• Only reproduces in headless  -p  mode; interactive mode is unaffected
• Impact: automation/headless workflows depending on the  skill  tool cannot assume it will resolve, even for a correctly installed skill

Reproduced in a fully isolated  COPILOT_HOME  profile (no custom hooks, no pre-existing skills/config/logs) with a single freshly created test skill — ruling out any local configuration, hook, or skill-content cause.

Activity

  1. added theissue type on Sep 14, 2026
  2. kristianAtMicrosoft commented on Sep 25, 2026

    @kristianAtMicrosoft

    I run into this same issue. The WorkIQ MCP Server comes with strict instructions for the AI harness to use its skills. But the AI harness can't find the skills when copilot is running in headless mode. This failure used to be intermittent. but with 1.0.88 it seems to happen all the time.

    Adding another repro on Windows, Copilot CLI 1.0.88, with a plugin skill (workiq@copilot-plugins v2.0.2). We launch copilot -p <prompt-file> -s --allow-all-tools from a background service. Three fresh processes over about 2.5 minutes all failed the same way. workiq was listed in that request's <available_skills> block, the log showed Plugin activation [skills]: plugins=1, loaded=10, and the workiq-* MCP tools were in the tool catalog. Even so, skill("workiq") returned Skill "workiq" not found. No model-invocable skills available. Right after that, copilot skill list showed the skill as enabled, and an interactive session could use WorkIQ normally. No extension attached during those sessions, so this doesn't look like the joinSession() trigger reported in #2753. Debug logs are available on request.

  3. kvnloo commented on Sep 27, 2026

    @kvnloo

    The strongest invariant here seems to be that tool resolution and prompt construction must bind to the same immutable skill-registry revision for a turn.

    If <available_skills> was rendered from registry revision R, then skill("x") during that turn must resolve against R, not a separately refreshed/empty registry.

    It would help to put a short registry revision/hash in debug logs at both points:

    prompt skills revision=abc123
    skill resolver revision=abc123

    Then a regression can deliberately refresh/discover skills concurrently and prove a turn never mixes revisions.

    This same pattern could probably eliminate several “UI sees it, model/tool does not” bugs.

  4. patniko commented on Oct 26, 2026

    @patniko
    Collaborator

    Thanks for the report. We've shipped fixes in this area since this was filed (most recently in Copilot CLI v1.0.97), and we believe this may now be resolved. Could you retest on the latest release (Copilot CLI v1.0.103) and let us know whether you still see it? If we don't hear back in a couple of weeks, we may close this issue — you can always reopen it.

    Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions