GitHub Copilot
How Pathrule integrates with GitHub Copilot across VS Code agent mode, the Copilot CLI, and the coding agent, through repo-level instruction files, hooks, MCP, and Agent Skills.
GitHub Copilot reads the same Pathrule team layer you get in Claude Code and Cursor: the same path scoped context, the same rule enforcement, and the same MCP tool surface. Copilot is unusual because one repo level file set feeds three surfaces at once. VS Code agent mode, the Copilot CLI, and the coding agent all read the files Pathrule writes under .github/, so a single integration covers all three.
This page covers what Pathrule writes for Copilot, how the surfaces differ, how the hook events map, and how to verify the integration.
What Pathrule writes
When you enable Copilot, Pathrule writes Copilot's own paths rather than inventing new ones. Every file lives under .github/, which is where Copilot already looks.
| File | What it does |
|---|---|
.github/copilot-instructions.md | The Pathrule protocol body, auto applied in agent mode and the CLI. |
.github/instructions/pathrule.instructions.md | An applyTo-scoped pointer that keeps the protocol present even when instruction matching is glob driven. |
.github/hooks/pathrule.json | The hook configuration. This is the one hook location all three Copilot surfaces read. |
.github/skills/<slug>/SKILL.md | Skills attached to your workspace, so Copilot can invoke them by name. |
Skills have one nuance. Copilot also reads .claude/skills. If you have both Claude Code and Copilot enabled on the same workspace, Pathrule skips .github/skills so Copilot does not see every skill twice. Enabling both clients produces no duplicated skills and no duplicated protocol in Copilot's context.
You can confirm what landed:
cat .github/copilot-instructions.md
cat .github/hooks/pathrule.json
Three surfaces, one file set
The same .github/ files light up each Copilot surface, but the surfaces differ in how hooks and MCP reach them.
| Surface | Hooks | MCP config location |
|---|---|---|
| VS Code agent mode | Reads .github/hooks; also reads .claude/settings.json when present | User level mcp.json, or registered in editor by the Pathrule VS Code extension |
| Copilot CLI | Reads .github/hooks | ~/.copilot/mcp-config.json |
| Coding agent (on github.com) | Reads .github/hooks; runs in a restricted sandbox | Repo Settings, configured by you (not file managed) |
For VS Code, the MCP config root key is servers, not mcpServers. If you use the Pathrule VS Code extension, Copilot agent mode is registered for you in the editor, with no MCP file to edit by hand.
The coding agent is the one surface Pathrule cannot wire from disk: its MCP servers are set in the repo's Settings on github.com, so pathrule doctor prints a short note pointing you there rather than silently doing nothing.
Hook event coverage
Copilot's hook events map to the same three injection points Pathrule uses on Cursor and Claude Code.
sessionStart. When a session begins. Pathrule returns the workspace overview so Copilot starts with the same shape it would read from an instructions file.postToolUse. After a tool finishes. Pathrule delivers the path scoped context for what the agent just touched, and captures activity.preToolUse. Before a tool runs. This is where a strict rule blocks a matching tool call before the change lands.
The per prompt event is deliberately not wired. Copilot's output for that event carries no additional context, so matching it would spend a process per prompt for no injection. SessionStart plus PostToolUse cover the same ground. The result is parity with the Cursor injection profile.
A single shared hook script handles every client. It detects the Copilot payload shape, normalizes it to one canonical form, runs the same rule and memory selection used for every other client, then writes back in Copilot's schema. You do not configure any of this per surface. The script is fail open by construction: an unrecognized or malformed payload returns nothing rather than breaking your Copilot session.
Install
Through Pathrule Desktop:
- Open the AI clients tab, enable GitHub Copilot.
- The app writes the
.github/files and the MCP config for the surfaces you use.
Through Pathrule CLI:
pathrule install --client copilot
pathrule sync
pathrule doctor --client copilot
Through the Pathrule VS Code extension, choose Copilot in Connect AI clients. The extension registers Copilot agent mode in the editor and writes the instruction files and hook config for you.
Verify
Open a workspace you attached to Pathrule and start a Copilot session on the surface you use.
- VS Code agent mode or the Copilot CLI. Start a new chat. The path scoped context should arrive before the first tool call. Edit a file under a path with attached knowledge and watch the relevant rules and memories surface. Trigger a strict rule and confirm the matching tool call is blocked.
- Coding agent. The
.github/files apply in the sandbox without error. Strict rules degrade to a deny in that restricted environment.
If the integration is silent:
pathrule doctor --client copilot
The doctor reports both MCP configs and whether the hook file is present, and it repairs stale entries. Disabling Copilot removes every file Pathrule owns.
What stays the same
Everything you write in Pathrule reaches Copilot with the same shape it reaches Claude Code and Cursor.
- A memory written from Pathrule Web shows up in Copilot.
- A strict rule blocks matching tool calls in Copilot.
- A skill is invokable by name in Copilot.
- The MCP tools (
pathrule_get_context,pathrule_write_memory, and the rest) behave identically.
You write knowledge once and every supported agent reads it.
What to read next
- Cursor for the sibling hook integration.
- One contract, every surface for why the same tool surface reaches every client.
- How hooks work for the underlying delivery model.
- Pathrule for VS Code for in editor registration of Copilot agent mode.