fetch_copilot_cli_documentation fails with ENOENT: README.md is declared in files[] but absent from released platform tarballs

[doomslayer2k]

Describe the bug

The built-in fetch_copilot_cli_documentation tool is documented as reading the CLI's own /help and README to answer capability questions (changelog 0.0.355, 2025-11-12: "Enabled the CLI agent to read its own /help and README to answer questions about its capabilities").

The README half fails. Calling the tool emits a raw filesystem error into model context:

ENOENT: no such file or directory, open 'C:\Users\<user>\.copilot\pkg\win32-x64\1.0.81-9\README.md'

The cause is self-contained and verifiable from the released artifact alone: README.md is declared in package.json → files[], but is not present in the released platform tarball. The install therefore cannot contain it, and the tool reads a path that never exists.

$ gh release download v1.0.81-9 --repo github/copilot-cli \
    --pattern "github-copilot-1.0.81-9-win32-x64.tgz"

$ tar -tzf github-copilot-1.0.81-9-win32-x64.tgz | grep -E "^package/[^/]+\.md$"
package/LICENSE.md          # <- README.md absent

$ tar -xzOf github-copilot-1.0.81-9-win32-x64.tgz package/package.json | grep '"README.md"'
    "README.md",            # <- but files[] declares it

So the packaging intent is intact and only the build output diverged from it — which is likely why this went unnoticed.

Affected version

GitHub Copilot CLI 1.0.81-9

Also verified absent in the released 1.0.80 and 1.0.81-0 platform tarballs, so this is not specific to one prerelease. A much older local install (0.0.410) does contain README.md (7,787 bytes), so it regressed at some point between the two.

Steps to reproduce

1. Install the CLI from a GitHub release (this is the channel the GitHub Copilot desktop app updates through).

2. Confirm the file is absent from the install:

   ls ~/.copilot/pkg/<platform>/<version>/*.md
   # LICENSE.md only

3. Dispatch any agent that has the tool and make it call it:

   copilot --allow-all-tools -p "Call fetch_copilot_cli_documentation and report exactly what it returned."

4. The response contains the ENOENT ... README.md error. The /help half returns normally, so the tool half-succeeds rather than failing cleanly.

Expected behavior

Either the released platform tarballs contain the README.md that files[] already declares, or the tool degrades gracefully — returning the /help content it does have without surfacing a raw ENOENT path into model context.

Additional context

Environment

copilot : GitHub Copilot CLI 1.0.81-9   (installed via GitHub release / desktop-app update channel)
OS      : Microsoft Windows 11 Enterprise 10.0.26200.0
Arch    : AMD64
Shell   : PowerShell 7.6.5
Terminal: ConsoleHost

Why this is invisible to anyone testing via npm

The npm-published package for the same version does contain README.md, because npm injects it regardless of files[] — per npm's files documentation:

Certain files are always included, regardless of settings: … README & LICENSE can have any case and extension.

Comparing the two publish paths for 1.0.80:

Artifact for 1.0.80	package/README.md
npm-published @github/copilot-win32-x64 (via mirror)	present
GitHub release github-copilot-1.0.80-win32-x64.tgz	absent

npm silently repairs the omission; the GitHub release tarball does not. So the defect only manifests on the release-tarball install path — which is the path the desktop app's updater uses. An npm i -g @github/copilot check would show the file present and suggest nothing is wrong.

(The npm-side artifact was fetched through a corporate registry mirror rather than registry.npmjs.org directly, which is network-blocked here. The primary evidence above does not depend on it — the files[]-vs-tarball mismatch is verifiable from the GitHub release asset alone.)

Impact

• A documented capability silently returns half its intended content, so the agent answers capability questions from /help alone and doesn't know the other half is missing.
• A raw filesystem path is surfaced into model context as an error string on every call.
• The tool takes no parameters, so there is no way for a caller to route around the broken half.

Scope not verified

Only win32-x64 was unpacked and inspected. The other platform tarballs are built from the same files[] manifest so they are very likely identical in this respect, but that is an inference, not a measurement. The exact version where the file stopped shipping was not bisected — only bounded between 0.0.410 and 1.0.80.

Suggested labels

area:installation, area:tools — filed unlabelled because an outside contributor has push:false / triage:false on this repo and cannot set labels or type.