---
source: CrewKit integrations
url: https://crewkit.io/integrations/cursor.md
title: "CrewKit for Cursor"
description: "Sync your team's rules and project memory into Cursor, and reach the same context from the CrewKit MCP server."
---


## What CrewKit adds to Cursor

Cursor is where a lot of the work happens, and it is also where a project's
accumulated knowledge is hardest to reach: the PRD is in a drive, the decision
is in a Slack thread, and the reason this module is written the way it is sits
in a conversation somebody had three weeks ago.

CrewKit turns that into something an editor session can query. Your team's rules
are maintained once and versioned; your project's documents, transcripts,
captured messages and analyzed past sessions become searchable project memory;
and `crewkit mcp serve` exposes both to any MCP-capable client, Cursor included.

## Before you start

- **The CrewKit CLI**, installed and logged in with `crewkit auth login`.
- **Git** — the organization and project are resolved from the working
  directory's git remote.
- **Node.js 18+** if you install through npm.

macOS arm64 and Linux x64 are the supported builds; on Windows, install the
Linux build under WSL. Claude Code is *not* a prerequisite for this path:
`crewkit mcp serve` asks only for your CLI login, your acceptance of the
acceptable-use policy and a project the CLI can resolve. Claude Code is required
only if you also want observed `crewkit code` sessions.

## Connect your project

Install the CLI by whichever of the three routes fits your machine:

```bash
npm install -g @crewkit/cli
brew install karibew/tap/crewkit
curl -fsSL https://crewkit.io/install.sh | sh
```

Then sign in and pin the project:

```bash
crewkit auth login
cd my-project
crewkit init
crewkit project create "My Project" --org acme
```

`crewkit init` pins the detected mapping in `.agent/config.yml` and nothing
more; `crewkit project create` is the server-side registration and takes an
organization slug or external ID, which keeps the step deterministic without an
interactive picker. `crewkit status` prints the resulting setup overview —
auth, project and sync state.

## Rules in your editor

Rules are plain markdown files, no frontmatter required, scoped by file path.
`backend.md` applies to files under `backend/`, `web.md` to files under `web/`,
`general.md` to everything. The file name is the whole routing rule — CrewKit
writes no configuration block for it — so pointing your editor at the convention
is up to you. A rule file is the place for the things a newcomer would otherwise
learn by review: the stack, that route handlers stay thin, that authorization
lives in middleware, that every query is scoped to the current account.

Like agents, skills and commands, rules exist at the platform, organization and
project tiers and are fetched as merged effective content. They are written to
`.claude/rules/` and checksummed, so a file you edited locally is backed up to
`.claude/.backups/` instead of being overwritten. Cursor does not read
`.claude/rules/`; those files remain the canonical copy in the repository, and
Cursor does not reach them over MCP either — the MCP tools carry playbook
conventions, project memory, prior work, active work and blueprint state, not
the rule files themselves. See [Rules](/docs/rules) and [MCP](/docs/mcp).

## Reaching project memory from Cursor

`crewkit mcp serve` runs a stdio MCP server. Register it in Cursor's MCP client
configuration:

```json
{
  "mcpServers": {
    "crewkit": {
      "command": "crewkit",
      "args": ["mcp", "serve"]
    }
  }
}
```

The server resolves your organization and project from the git remote of the
working directory. When that is not possible, override it:

```bash
crewkit mcp serve --org <org-id> --project <project-id>
```

The `CREWKIT_ORG_ID` and `CREWKIT_PROJECT_ID` environment variables do the same
thing. Authentication uses your CLI login; signed out, tool calls return an
actionable error rather than failing silently.

From there the editor can call `search_project_context` for hybrid lexical and
semantic search over uploaded docs, meeting transcripts, captured Slack
messages, Drive imports and indexed past sessions; `find_prior_work` to find the
conversation where someone already solved this; `get_conventions` for the
playbook conventions governing the project; `get_active_work` for who is on
what right now; and `get_blueprint_state` for the active plan. Project memory
itself is managed in the dashboard under Projects, then Documents, which accepts
PDF, Markdown, plain text and Word files. See [Artifacts](/docs/artifacts).

## What this does not do yet

- **No Cursor-native rules export.** Rules are written to `.claude/rules/`, a
  path Cursor does not read, and the CLI has no option to emit them in another
  editor's rules format or to carry them over MCP — inside Cursor, rules stay
  reachable only by opening the file.
- **Editor sessions are not observed.** Session telemetry — turns, tokens, cost,
  subagent task stats, the post-session summary and coaching tips — comes from
  Claude Code hooks. Work done in Cursor does not appear in the dashboard's
  session or analytics views.
- **Inbound captures wait for a human.** Slack messages and email captured for a
  project land in the Inbox and are not injectable context until someone
  confirms them, so the newest material may not be searchable yet.
- **Sensitive and private sessions are excluded** from cross-session discovery
  by design, so `find_prior_work` will not surface them.
- **`add_note` needs a CrewKit-launched session.** The MCP tool that writes a
  durable note into project memory reads a session id only `crewkit code` sets,
  so a hand-registered Cursor client gets an error instead. Reads are unaffected.

The full tool list and its limits are on
[the CrewKit MCP server](/integrations/mcp) page.