Claude Code

How Pathrule CLI connects Claude Code through hooks, instruction files and MCP, and how Claude Code can also reach a workspace through Remote MCP.

On this page

Two layers, one workspace
Companion files
Rule enforcement
Install
Remote MCP
Verify
When Claude writes content
What to read next

Claude Code connects to your Pathrule workspace through Pathrule CLI or the VS Code extension. Pathrule provides two integration layers: hooks that push path scoped context before the agent acts, and MCP tools that Claude can pull from when it wants more. Claude Code is one of the two clients, with Codex, that Pathrule reaches with a prompt-submit hook.

This page covers what gets written into your project, how the two layers fit together, and how to verify the integration end to end.

Two layers, one workspace

Hooks (push). Claude Code invokes Pathrule's hook supervisor at session start, on every prompt and around file and shell tool calls. The supervisor reads a precomputed slice from the local cache and returns it as context.
MCP tools (pull). When the hook payload is not enough (discovery prompts, full memory bodies, writes), Claude calls the Pathrule MCP server directly through tools like pathrule_get_context and pathrule_write_memory.

Hooks are the default. MCP tools are the deep path. The same content tree drives both.

Event	What Pathrule does
`SessionStart`	Hands Claude the workspace id and root, the Pathrule protocol and your team context, once per session.
`UserPromptSubmit`	Scopes the turn: the rules and memories that fit the prompt, with the strongest memories as full bodies, and matching skills by name.
`PreToolUse`	Before a read, edit, write, search or shell call: names and one-line summaries of what applies to that path, the block-pattern check for edits and writes, and the teammate conflict check.
`PostToolUse`	Records what happened, including failed tool calls, so the session's activity and recurring friction are captured.
`Stop`, `SubagentStop`, `SessionEnd`	Close the turn and the session. An approved required check can hold the turn open here until its command has passed.

Companion files

When you install Pathrule into Claude Code, these are the files involved.

~/.claude.json. Claude Code's user config. Pathrule adds its MCP server entry here and leaves your other servers alone.
.claude/settings.json in the project. Pathrule merges its hook registrations into this file and keeps any hooks you added yourself.
.claude/rules/pathrule/ in the project. Claude Code's path-scoped rules: workspace.md, loaded at session start, and one file for each area with knowledge, whose paths: header makes Claude Code load it only when work enters that area. A manifest.json records which memory versions these files hold, so the hook does not deliver them twice, and the folder's own .gitignore keeps it out of git without touching yours.

The protocol does not have to live in a file. When the Claude Code hook is installed, the protocol rides the SessionStart hook, and path knowledge arrives through the per-prompt and per-tool hooks and the .claude/rules/pathrule/ files, so Pathrule removes the protocol copy and the knowledge files it wrote in earlier versions. Beyond the hook registration and that folder, it writes nothing into your tree, and your own CLAUDE.md stays yours. If the hook is not installed, or PATHRULE_SIGNATURE_MODE=off is set, Pathrule falls back to compiled files: a protocol copy in .claude/rules/pathrule-protocol.md, workspace knowledge in .claude/rules/pathrule-knowledge.md and a CLAUDE.md in each directory that has knowledge attached.

Rule enforcement

A rule has a priority (high, medium, low) that ranks how it surfaces. Priority does not decide blocking. A rule blocks only when it carries an approved block pattern: a forbidden form in the content, a forbidden location for the file, or both.

An assistant can propose a block pattern when it writes or updates a rule. The proposal is stored with the rule as a proposal and is not enforced. An agent cannot approve it; nothing blocks until a person has approved the pattern.
On PreToolUse, before an edit or a write, the hook checks the new content and the target path against every rule with an approved block pattern for that path, whatever its priority.
If one matches, the hook denies the tool call before the file is written. Claude sees Pathrule blocked: with the rule name, a preview of the rule, the approved "do this instead" message and a pointer to the full rule, and retries inside the constraint.

Every other rule is advisory. It rides along as context and the assistant decides how to apply it. Blocking runs through the local hook; Remote MCP has no hooks, so it surfaces rules as context only.

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, writes the MCP entry into ~/.claude.json and every other AI client's configuration, and writes the hook and the .claude/rules/pathrule/ files. --target claude writes the MCP entry for Claude Code only. Run pathrule setup --local instead to use Pathrule with no account; knowledge then stays on this machine.

To wire the pieces by hand in a folder that is already attached:

pathrule install claude
pathrule sync
pathrule doctor

pathrule install claude adds the MCP entry to ~/.claude.json. pathrule sync installs the hook script, registers the hooks in .claude/settings.json and writes the .claude/rules/pathrule/ files.

Through the VS Code extension, choose Claude Code in Connect AI Clients. The extension writes the same MCP entry and hook configuration through its bundled CLI.

Remote MCP

Claude Code can also connect to the hosted endpoint, with no local install:

claude mcp add --transport http pathrule https://cloud.pathrule.io/mcp

Then complete the OAuth sign-in with your Pathrule account. Remote MCP gives Claude the MCP tools only: it installs no hooks, writes no local files and has no local mode. See Pathrule Remote MCP.

Verify

Open Claude Code in a directory you attached. Start a new turn. The Pathrule section should appear in the context surface before the first tool call, listing the path it resolved, the matching rules, the strongest memory bodies and any less-certain candidates by title.

If nothing appears, run:

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 Claude Code 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. To put everything back in place, run:

pathrule install claude
pathrule sync

pathrule install claude rewrites a stale MCP entry and leaves your other servers alone, and pathrule sync writes the hook entry and the .claude/rules/pathrule/ files again. If you connected Claude Code with pathrule integrations, pathrule integrations repair applies that integration again. Run the doctor once more to check.

When Claude writes content

Claude can write memories, rules, and skills back into Pathrule using the MCP write tools. The runtime tags the source as claude, so content an AI wrote stays distinguishable from content a person wrote.

Use the pathrule_log_activity tool to make every file modifying response visible in the activity log. This is the bridge between what Claude did and what your team sees.