Windsurf

Windsurf talks to Pathrule the same way every other client does: a local MCP server entry plus a companion instruction file that Windsurf reads at session start. You get the same path-scoped content, the same rules, and the same MCP tools you get in Claude Code or Cursor. Only the client config differs.

This page covers what Pathrule writes into your project 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 Windsurf's config. It points the assistant at the local Pathrule MCP server so it can call the pathrule_* tools.
• A companion instruction file rendered in the format Windsurf reads. It carries the workspace overview and the Pathrule protocol, the same substance the other clients get in their own native formats.
• Materialized skills attached to your workspace, so Windsurf can invoke them by name.

The companion file is not hand-copied per client. Pathrule generates it from a shared renderer that also produces the Claude Code, Cursor, and Codex instructions, so the four stay in sync instead of drifting apart over time.

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 as a first-class client. For Windsurf, Pathrule writes that config for you and renders the companion file alongside it. The companion file delivers the workspace overview and protocol at session start; the MCP tools deliver everything deeper on demand.

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 companion file and the materialized skills are rendered views, not the canonical copy. A memory written from Pathrule Web reaches Windsurf with the same shape it reaches every other client.

Pathrule has no tool that reads your filesystem. Your source code stays on your machine; only the team-written content (memories, rules, skills) is stored.

One content layer, many delivery formats

The instruction format each client reads differs, so Pathrule produces every companion file from the same shared renderer rather than hand-copying one per tool. That keeps the Windsurf protocol identical in substance to the Claude Code, Cursor, and Codex versions, even though the file format differs.

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.

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 that the CLI and Desktop use, 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 One contract, every surface for why the tool surface stays identical across every surface.

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.

The choice is whatever you pick in Pathrule Desktop's AI clients tab, or whichever clients you install with pathrule install.

Install

Through Pathrule Desktop:

1. Open the AI clients tab, enable Windsurf.
2. The app writes the MCP entry, renders the companion file, and materializes any attached skills.

Through Pathrule CLI:

pathrule install windsurf
pathrule sync
pathrule doctor --client windsurf

Verify

Open Windsurf in a directory you attached to a workspace. The assistant should read the companion file at session start and be able 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 --client windsurf

The doctor reports which step is off: a missing MCP entry, a server that is not reachable, or a working directory the runtime cannot resolve to a workspace.

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 strict rule still blocks a matching change.
• A skill is invokable by name.
• The MCP tools behave identically.

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

What to read next

• Cursor for the sibling VS Code-fork integration with native hooks.
• One contract, every surface for why the tool surface is the same everywhere.
• Pathrule for VS Code for the extension that can register Windsurf from inside the editor.
• How hooks work for the delivery model behind the content.