Using Claude with Cursor

These are two separate programs

It is worth stating plainly, because the naming invites confusion: Cursor and Claude Code are different products from different companies. Cursor is an editor with an agent built in. Claude Code is Anthropic’s coding agent, used from a terminal or as an editor extension. You can absolutely use both at once — many people do — but they each keep their own configuration, in their own files.

The mistake that costs the most time is assuming a setting you wrote for one applies to the other. It usually does not. Here is the actual division:

In a project using both, the files sit side by side like this:

your-project/
├── .cursor/
│   ├── rules/conventions.mdc   read by Cursor only
│   └── mcp.json                Cursor's MCP servers
├── .mcp.json                   Claude Code's MCP servers (project scope)
├── .claude/settings.json       Claude Code settings, shared
└── CLAUDE.md                   read by BOTH tools

The overlap: CLAUDE.md

This is the fact that reorganises everything else. Cursor’s documentation states that Cursor reads CLAUDE.md the same way it reads AGENTS.md — except that CLAUDE.md files are always applied to every conversation, regardless of any alwaysApply frontmatter setting.

The reverse is not true. Claude Code’s documentation is explicit that it reads CLAUDE.md, not AGENTS.md, and there is no documented mechanism by which it consults .cursor/rules while running. The only sanctioned bridge is /init, which reads your existing Cursor rules — either .cursor/rules/ or a legacy .cursorrules — and folds the relevant parts into the CLAUDE.md it generates. That is a one-time import at generation time, not an ongoing sync.

Used deliberately, the asymmetry is genuinely useful: CLAUDE.md is the only file that reliably reaches both tools. That makes it the right home for instructions that must hold no matter who is driving. The full precedence detail is in CLAUDE.md vs .cursor/rules.

Rules: keep one owner per topic

Because .cursor/rules is Cursor-only and CLAUDE.md reaches both, the sensible split is:

• Universal, tool-agnostic instructions — what not to touch, how to handle secrets, testing expectations — go in CLAUDE.md, because both agents will honour them.
• Cursor-specific, file-scoped conventions go in .cursor/rules with globs, so they attach only where they are relevant. Claude Code will not see them, which is fine — that is the point of scoping.
• Personal preferences go in your user-level config on each side — Cursor’s Customize → Rules, or ~/.claude/CLAUDE.md — never in the shared repo.

What you must not do is state the same policy in both places in different words. There is no cross-tool precedence rule to adjudicate that; you will simply get whichever phrasing the model weighted more heavily that day.

Two MCP systems, configured separately

Both tools speak MCP, and neither reads the other’s configuration. Adding a server to Cursor does not add it to Claude Code.

Cursor uses .cursor/mcp.json per project and ~/.cursor/mcp.json globally, merged, with the project file winning on a name collision.

Claude Code has three documented scopes: local (the default — current project only, stored in ~/.claude.json), project (stored in .mcp.json at the project root, meant to be version-controlled and shared with your team), and user (available across all your projects). You choose with -s or --scope:

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

Note the -- separator is required before the command when adding a stdio server rather than an HTTP one.

For diagnosing a server that will not connect on the Cursor side, see MCP server stuck red in Cursor.

Claude Code’s settings precedence

Worth knowing if you are sharing a repo with a team, because a teammate’s local file can override what you committed. From highest priority down: managed settings, then command-line arguments, then .claude/settings.local.json, then .claude/settings.json, then ~/.claude/settings.json.

Memory files behave differently from settings, and the difference catches people: CLAUDE.md files are concatenated, not overridden. They load broadest scope first — managed policy, user, project, then CLAUDE.local.md — so a project instruction simply appears later in context than a user one. Nothing is replaced. If you have contradictory instructions at two levels, both are present.

Running Claude Code inside Cursor

Two ways, both straightforward. Because Cursor is a VS Code fork, the Claude Code VS Code extension installs directly into it — Anthropic’s docs provide a cursor:extension/anthropic.claude-code install link. Or just run the CLI in Cursor’s built-in terminal; it works in any terminal.

What is not documented anywhere is any sharing of credentials, rules, or MCP configuration between the two when you do this. Running Claude Code inside Cursor’s window does not put it inside Cursor’s configuration. It is the same independent tool that happens to be running in that terminal — treat it accordingly and you will not be surprised.

A workflow that stays sane

1. Run /init once, early, so Claude Code starts from your existing Cursor rules rather than from nothing.
2. Decide deliberately what belongs in CLAUDE.md, knowing that Cursor obeys it too. Keep it short — it is in the context of every conversation in both tools.
3. Leave file-scoped conventions in .cursor/rules. Do not duplicate them into CLAUDE.md.
4. Set up MCP twice, on purpose, and verify each side independently rather than assuming one proves the other.
5. When behaviour surprises you, ask the agent which instructions it is currently operating under. Both tools will tell you, and it is faster than re-reading your own files.

What to read next

New to the Claude Code CLI? Getting started with Claude Code. The precedence details behind the overlap are in CLAUDE.md vs .cursor/rules. If you are still carrying a legacy rules file, clear it up with .cursorrules is deprecated.