PathruleGitHub Copilot
How Pathrule CLI connects GitHub Copilot in VS Code agent mode and the Copilot CLI through the local MCP server, and what the coding agent on github.com needs.
On this page
GitHub Copilot connects to your Pathrule workspace through Pathrule's local MCP server. Pathrule CLI writes the MCP entries, and the VS Code extension registers Pathrule for Copilot agent mode inside the editor. Pathrule writes no .github/ files and no hooks for Copilot, so context arrives when Copilot's agent calls Pathrule's MCP tools, not before each prompt. Remote MCP setup is not documented for Copilot.
This page covers what Pathrule writes for Copilot, how its surfaces differ, how knowledge reaches it, and how to verify the integration.
What Pathrule writes
Pathrule writes Copilot's own MCP configuration files and nothing in your repository.
| File | What it does |
|---|---|
~/.copilot/mcp-config.json | The Copilot CLI's MCP configuration, with Pathrule's server entry beside your other servers. |
VS Code's user mcp.json | VS Code's MCP configuration for Copilot agent mode, with the root key servers, not mcpServers. |
Both entries point at the local Pathrule MCP server, and they are the same for every folder: the server answers each call from the Pathrule Cloud or Pathrule Local workspace of the folder it is about. When the same repository is also used with Claude Code or Codex, those clients get their own hooks and files as usual.
Three surfaces, one workspace
Copilot runs in three places, and MCP reaches each one differently.
| Surface | MCP config location |
|---|---|
| VS Code agent mode | User level mcp.json, or registered in the editor by the Pathrule VS Code extension |
| Copilot CLI | ~/.copilot/mcp-config.json |
| Coding agent (on github.com) | Repository settings on github.com, configured by you (not file managed) |
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. It works from what is committed to the repository, and its MCP servers are set in the repository's settings on github.com, outside any file Pathrule manages, so Pathrule does not configure MCP for it.
How knowledge reaches Copilot
Copilot's agent reaches the same MCP tools as every other client:
pathrule_get_contextreturns the memories, rules and skill names that fit the folder it is working in.pathrule_read_memory,pathrule_read_ruleandpathrule_read_skillread a full body by id.- The write tools, such as
pathrule_write_memory, save memories, rules and skills when you ask.
Context arrives when the agent calls these tools. There is no Pathrule hook in Copilot to hand it over before the first tool call, so ask the agent to check Pathrule when a task starts, or say so in your own Copilot instructions.
A rule reaches Copilot as context the agent reads. It cannot block an edit there: blocking a matching edit runs in Pathrule's pre-tool hook, which Claude Code and Codex have.
Install
Through Pathrule CLI:
pathrule setup
Run it in the project folder. On a new install it sets the folder up on Pathrule Cloud: it signs you in when needed, attaches the folder to a workspace, and writes the MCP entries for Copilot and every other AI client. --target copilot writes them for Copilot only. Run pathrule setup --local instead to use Pathrule with no account.
To add the entries by hand:
pathrule install copilot
pathrule doctor
pathrule install copilot writes the Pathrule server into both MCP configs, ~/.copilot/mcp-config.json for the Copilot CLI and VS Code's user mcp.json, and leaves every other server in those files alone.
Through the Pathrule VS Code extension, choose GitHub Copilot in Connect AI Clients, or rely on the extension's own registration of Copilot agent mode in the editor.
Verify
Open a workspace you set up and start a Copilot session on the surface you use.
- VS Code agent mode or the Copilot CLI. Confirm that the
pathruleMCP server is listed and enabled, start a new chat, and ask the agent to callpathrule_get_contextfor the current directory. It should return the workspace's knowledge for that path. - Coding agent. Add an MCP server in the repository's settings on github.com if you want it to call tools.
If the integration is silent:
pathrule doctor
The doctor is read-only. It reports which edition serves this folder, your sign-in and whether this folder is attached in a Cloud folder, lists Copilot twice, once for the Copilot CLI config and once for VS Code's mcp.json, so a half-installed setup shows up, and shows which Pathrule-managed files are in the folder and who wrote them. Add --json for the full report, which names each config path and also flags an MCP entry that points at a runtime that no longer exists. To fix that, run:
pathrule install copilot
pathrule install copilot rewrites both Pathrule MCP entries and leaves your other servers untouched. Run the doctor once more to check. pathrule uninstall copilot removes the Pathrule entry from both MCP configs.
What stays the same
Everything you write in Pathrule reaches Copilot with the same content it reaches Claude Code and Cursor.
- A memory written by any agent through MCP, in the Local Console or in VS Code is returned to Copilot by the same tools.
- A rule is the same rule. Copilot reads it as context; Claude Code and Codex can also block a matching edit with it.
- A skill is read by name with
pathrule_read_skill. - 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 integration over MCP.
- Local and Remote MCP for why the same tool surface reaches every client.
- How hooks work for the delivery model of the clients that have hooks.
- Pathrule for VS Code for in editor registration of Copilot agent mode.