System prompt still instructs the model to use grep, glob, view and lsp after --available-tools has removed them

Version

1.0.80 — self-reported by the CLI inside the system prompt it sends (<version_information>Version number: 1.0.80</version_information>), so the version and the defect come from the same captured request.

What happens

When --available-tools narrows the tool set (in my case to a single MCP server's tools), the tool declaration is correctly narrowed — the request carries exactly the allowed tools and nothing else. But the system prompt is not narrowed with it. Three sections continue to instruct the model to use tools that are no longer available:

• <tool_preferences> — "Use the grep tool instead of commands like grep/rg in bash · Use the glob tool instead of commands like find/ls · Use the view tool instead of commands like cat/head/tail"
• <code_search_tools> — "Prefer calling in the following order: Code Intelligence Tools (if available) > lsp (if available) > glob > grep with glob pattern"
• <exploration_and_reading_files> — instructions on batching view calls

The model follows them, the calls are rejected at the tool boundary (Tool 'view' does not exist. Available tools that can be called are …), and the turn is spent.

Note this is not uniform behaviour across sections: dropping the skill tool does remove the <available_skills> block from the prompt. So some sections are already tool-conditional and these three appear not to be, which is what makes this look like an oversight rather than a design decision.

Reproduction

copilot -p "read the file ./notes.txt and summarise it" \
  --available-tools <one-mcp-server-tool> \
  --allow-tool <that-server> \
  --disable-builtin-mcps \
  --no-custom-instructions

Inspect the outgoing request (any HTTPS proxy will show it). The tools array contains only the allowed tool; the system content still contains the three sections above.

Impact

The model wastes turns on tools it cannot call, and each one is billed. In one of my sessions the model tried twice in a row:

turn 3   view  path=/tmp/copilot-tool-output-176a24.txt
         → Tool 'view' does not exist.
turn 5   bash  cat /tmp/copilot-tool-output-1789a0.txt
         → Tool 'bash' does not exist.

Both were the prompt's advice followed literally. Beyond the cost, it makes a restricted-tool session behave measurably differently from what the flag implies, which matters if you are using the CLI as a controlled harness.

What I checked for a workaround

• Every flag in copilot --help on 1.0.80. --no-custom-instructions closes the custom-instructions channel and nothing else; --available-tools and --excluded-tools both affect availability, not the prompt.
• Every variable in copilot help environment. None gates prompt assembly.
• Hook surface: none documented.

Suggested fix

Make these three sections conditional on the corresponding tools actually being available, the way <available_skills> already is.

Start by running the provided copilot command with --available-tools and inspecting the outgoing request, comparing the narrowed tools array with the system prompt. Trace the prompt assembly for <tool_preferences>, <code_search_tools>, and <exploration_and_reading_files>, using the existing <available_skills> behavior as a reference; done means unavailable tools are no longer recommended in those sections.