Repository navigation
skill tool intermittently fails in headless -p mode: "No model-invocable skills available" #4838
Description
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
- Install a user-level skill at ~/.copilot/skills//SKILL.md (supported path, no disable-model-invocation policy).
- 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 - Repeat several times in quick succession (some spaced 6–90s apart).
- 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
kristianAtMicrosoft commentedon Sep 25, 2026
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-pluginsv2.0.2). We launchcopilot -p <prompt-file> -s --allow-all-toolsfrom a background service. Three fresh processes over about 2.5 minutes all failed the same way.workiqwas listed in that request's<available_skills>block, the log showedPlugin activation [skills]: plugins=1, loaded=10, and theworkiq-*MCP tools were in the tool catalog. Even so,skill("workiq")returnedSkill "workiq" not found. No model-invocable skills available.Right after that,copilot skill listshowed the skill as enabled, and an interactive session could use WorkIQ normally. No extension attached during those sessions, so this doesn't look like thejoinSession()trigger reported in #2753. Debug logs are available on request.kvnloo commentedon Sep 27, 2026
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 revisionR, thenskill("x")during that turn must resolve againstR, 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=abc123skill resolver revision=abc123Then 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.
patniko commentedon Oct 26, 2026
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.