Skip to content
Pathrule

pathrule.iodocs

Pathrule

docs

DocsGet started

Windsurf

How Pathrule CLI connects Windsurf through the local MCP server, with the same Pathrule tools every other client uses.

On this page

Windsurf connects to your Pathrule workspace through Pathrule's local MCP server. Pathrule CLI writes the MCP entry, and the VS Code extension can write it from inside Windsurf. Pathrule writes no rules file and no hooks for Windsurf: the MCP tools deliver the workspace knowledge when Windsurf's agent calls them. Windsurf uses the local MCP server; Remote MCP setup is not documented for Windsurf.

This page covers what Pathrule writes for Windsurf, why the same content reaches Windsurf as every other tool, and how to verify the integration yourself.

What Pathrule writes

When you install Pathrule into Windsurf, you get:

  • An MCP server entry in ~/.codeium/windsurf/mcp_config.json. It points the assistant at the local Pathrule MCP server so it can call the pathrule_* tools, and leaves your other servers alone. The entry is the same for every folder: the server answers each call from the Pathrule Cloud or Pathrule Local workspace of the folder it is about.

That is all Pathrule writes for Windsurf: no .windsurf/rules files and no hooks. When the same repository is also used with Claude Code or Codex, those clients get their own hooks and files as usual.

How the content reaches Windsurf

Any tool that speaks MCP can use Pathrule over stdio: add the Pathrule MCP command to the client config, and the assistant sees the same tool surface. For Windsurf, Pathrule CLI writes that config. The MCP tools deliver the workspace knowledge on demand: pathrule_get_context returns what fits the folder the agent is working in, and the read tools return full bodies. Ask the agent to check Pathrule when a task starts, or say so in your own Windsurf rules.

Two facts make this work without per-client divergence.

  • One tool contract. The MCP tools (pathrule_get_context, pathrule_read_memory, pathrule_write_memory, and the rest) are the same set Claude Code and Cursor call. The assistant fetches context and writes memories, rules, and skills through the identical surface; the client config is the only thing that changes.
  • One source of truth. The workspace is the canonical copy. A memory written by any agent through MCP, in the Local Console or in VS Code reaches Windsurf with the same content it reaches every other client.

Pathrule does not automatically upload your repository source code. Local project-learning tools can inspect the files attached to a finding to validate it. What is stored is your team's knowledge (memories, rules, skills), the activity agents log, the findings agents record with the files they rest on, and, on a cloud workspace, the file path pairs Pathrule reads from recent git history to learn which files change together. See what Pathrule computes for what is sent and stored in Cloud mode.

One content layer, every client

The investment lives in the content layer, not in the client. The same memories, rules, and skills serve Windsurf and every other client without rewriting anything. What differs is the delivery: Claude Code and Codex also get hooks that hand context over before the agent acts, and Windsurf asks for it through MCP.

Through the VS Code extension

Windsurf is a VS Code fork. If you run the Pathrule VS Code extension inside Windsurf, the extension detects the host and writes the same managed MCP entry through the installer the CLI uses, with no hand-edited JSON. That entry points at the bundled Pathrule runtime and never carries secrets.

This is one more entry point to the same workspace, not a separate integration. See Pathrule for VS Code for what the extension does and Local and Remote MCP for the differences between local stdio and Remote MCP.

Per client isolation

Windsurf coexists with Claude Code, Cursor, and Codex on the same machine. You can install one client, several, or all of them.

  • They share the same Pathrule workspace, the same MCP server, and the same content tree.
  • The configs each client reads are independent. Installing Windsurf does not touch the others.
  • Removing one client leaves the rest, and the content, untouched.

pathrule setup writes the entry for every client it supports. pathrule setup --target windsurf or pathrule install windsurf writes it for Windsurf alone, and in the VS Code extension Connect AI Clients lets you pick the clients.

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 entry into ~/.codeium/windsurf/mcp_config.json and every other AI client's configuration. Run pathrule setup --local instead to use Pathrule with no account.

To add the entry by hand:

pathrule install windsurf
pathrule doctor

pathrule install windsurf adds the MCP entry to ~/.codeium/windsurf/mcp_config.json.

You can also use the VS Code extension running inside Windsurf, as described above.

Verify

Open Windsurf in a directory you set up. Confirm that the pathrule MCP server is enabled in Windsurf, then ask the agent to call pathrule_get_context against your working directory.

Run a prompt that touches a path with content. The assistant should surface that content through the MCP tools. If it cannot:

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, whether the Pathrule MCP entry is installed for Windsurf and each other client, and which Pathrule-managed files are in the folder and who wrote them. Add --json for the full report, which also flags an MCP entry that points at a runtime that no longer exists. pathrule install windsurf rewrites a stale entry.

What stays the same

The content layer is identical across clients.

  • The same memory that shows up to Claude Code through the hook shows up to Windsurf through the MCP tools.
  • A rule reaches Windsurf through MCP. Windsurf has no Pathrule hook, so a rule cannot block an edit there; pre-write blocking runs only in clients with Pathrule's tool hooks: Claude Code and Codex.
  • A skill is read by name with pathrule_read_skill.
  • The MCP tools behave identically.

If your team writes content for one assistant, every assistant gets it.

What to read next