How to Use Claude Code and Cursor Together

I use both Claude Code and Cursor every day. Not as a compromise, and not because I haven’t made up my mind — because they cover genuinely different parts of my workflow. For a long time the conversation around these tools has been framed as a competition. Pick one, commit, move on. I think that framing misses the point entirely. Once I started treating them as complementary rather than competing, my productivity noticeably shifted. This post explains exactly how I use them together.

Step-by-step: set up Claude Code and Cursor together

This workflow works best when both tools point at the same repository, share the same project conventions, and have clearly different jobs. Claude Code handles the macro task. Cursor stays with the file you are actively editing.

macOS

1. Download the macOS build of Cursor from cursor.com/download and install it.
2. Open Cursor once and complete the first-run setup.
3. In Terminal, install Claude Code with curl -fsSL https://claude.ai/install.sh | bash.
4. Verify the install with claude --version and claude doctor, then run claude once to authenticate.
5. Open the same repository in Cursor and let indexing finish before you start prompting both tools.

Linux

1. Download the Linux build of Cursor from cursor.com/download. Use the .deb package on Ubuntu or Debian, the .rpm package on Fedora or RHEL-family systems, or the AppImage if you want a portable install.
2. Install the package or make the AppImage executable, then open Cursor once.
3. Install Claude Code with curl -fsSL https://claude.ai/install.sh | bash.
4. Verify the install with claude --version and claude doctor, then run claude to authenticate.
5. Open the same repository in Cursor and let indexing finish before you start prompting both tools.

Windows

1. If your repository lives in WSL, run wsl --install first and finish the Ubuntu setup. That keeps Claude Code and your Unix tooling in the same environment.
2. Install the Windows build of Cursor from cursor.com/download and open it once.
3. Install Claude Code either inside WSL with curl -fsSL https://claude.ai/install.sh | bash or natively in PowerShell with irm https://claude.ai/install.ps1 | iex.
4. Verify the install with claude --version and claude doctor, then run claude once to authenticate.
5. Open the same repository in Cursor and let indexing finish before you start prompting both tools.

1. Install Claude Code in the environment where the repo actually lives. Use the native installer on macOS, Linux, or WSL, or the official PowerShell installer if you are staying on native Windows.
2. Verify the install with claude --version and claude doctor, then run claude once to authenticate.
3. Install the Cursor desktop app, open the same repository, and let it finish indexing before you expect good answers.
4. Put persistent instructions in CLAUDE.md for Claude Code and in .cursor/rules/*.mdc for Cursor project rules.
5. Use Claude Code for end-to-end tasks such as “write the integration tests” or “refactor this service”. Use Cursor for inline drafting, quick edits, and file-level questions.
6. Do not let both tools edit the same file at the same time. Finish the Claude task, review the diff, then continue in Cursor.

Official Claude Code install commands:

For Cursor itself, use the platform-specific installer from cursor.com/download. If you want terminal launch integration later, use Cursor’s Command Palette and run Shell Command: Install 'cursor' command in PATH.

A minimal Cursor project rule now lives under .cursor/rules, not in the legacy root-level .cursorrules file:

---
description: Core project conventions
alwaysApply: true
---

- TypeScript strict mode
- Named exports only
- Write tests for behavioral changes
- Explain any deployment or schema change in the PR

---
description: Core project conventions
alwaysApply: true
---

- TypeScript strict mode
- Named exports only
- Write tests for behavioral changes
- Explain any deployment or schema change in the PR

The Basic Principle

The clearest way I can put it: Claude Code is for tasks you’d describe to another developer. Cursor is for work you’re actively doing yourself, with AI assistance alongside you.

That distinction sounds subtle but it changes everything about how you reach for each tool. When I have a task that I could hand off — “write a full test suite for this authentication module,” “refactor this service to use dependency injection,” “add error handling across these API routes” — that’s a Claude Code task. I describe it, I hand it over, and I go do something else. Claude Code works through it autonomously, makes decisions, runs commands, edits files. I come back and review.

When I’m in the middle of writing something myself — a new feature, a tricky function, a PR review where I want a second opinion on a specific block of code — that’s a Cursor moment. I want inline suggestions, I want to highlight a selection and ask a question, I want the AI woven into my active editing session. Cursor is built for that mode of working. Claude Code isn’t trying to be.

Different modes of working. Different tool. Run them both.

A Typical Day

Here’s roughly how a working day looks when both tools are in play.

Morning. I open the terminal and fire up Claude Code. There’s usually something on my list that’s significant enough to delegate entirely: yesterday it was writing integration tests for a data-pipeline service I’d just finished. I described the task, pointed it at the relevant files, and let it run. Claude Code goes off and works — it reads the codebase, decides on test structure, writes the files, runs the tests, and iterates on failures. This takes anywhere from 5 minutes to 30 minutes, depending on the scope.

Meanwhile. I switch to Cursor and work on something entirely separate. This morning that was a new feature in a different part of the codebase. I’m writing the code myself, but Cursor’s inline completions fill in repetitive parts, and when I reach a decision point, I ask it directly in the chat panel. The two tools are running in parallel — in different terminals, with different concerns, no collisions.

Coming back to Claude Code. When the task finishes, I review the diff. This is where Claude Code’s conversational interface earns its keep. I can ask questions inside the same session: “Why did you structure the mocks this way?” or “Can we simplify this setup block?” It explains its reasoning, and if I want changes, I ask for them. The iteration loop stays in one place.

Afternoon. More of the same pattern, scaled down. Smaller background tasks in Claude Code — maybe updating API documentation, or making a consistent change across a set of files. Smaller active work in Cursor — polishing the feature I started in the morning, or fixing a bug that came up in review. The rhythm is parallel rather than sequential, and that’s the whole point.

Managing Context

The main discipline this workflow requires is keeping the two tools separate. The rule I follow is simple: don’t have both touching the same file at the same time.

It sounds obvious, but it’s easy to let it slip. Claude Code is working on a module, and you get curious and open the same file in Cursor to check something. Now you’ve got two processes with potentially conflicting views of that file. If you edit it in Cursor while Claude Code is mid-task, you risk confusing the session or creating a merge situation when Claude Code writes its changes. It’s not catastrophic — git handles it — but it’s unnecessary friction.

A cleaner mental model is to think of Claude Code handling macro tasks and Cursor handling micro ones. Macro: refactoring a whole service, writing a complete test suite, and implementing a feature end-to-end from a spec. Micro: writing the body of a function, adjusting a component’s behavior, fixing a specific bug. There’s naturally less overlap when you frame it that way. Macro tasks tend to be scoped to files or modules you’re not actively working in. Micro tasks are the files you have open right now.

When there is overlap — when Claude Code finishes on a file you then need to work in — just let the task complete, review the diff, and then pick it up in Cursor. The handoff is clean.

The CLAUDE.md and Cursor Rules Connection

Both tools work better when the repository itself tells them how the project works.

Claude Code reads CLAUDE.md at the start of a session. Cursor’s current project-rules system lives under .cursor/rules/*.mdc. The older .cursorrules file is still supported, but Cursor documents it as a legacy format rather than the default path.

The practical point is that both tools should agree on the fundamentals: naming conventions, testing expectations, architecture boundaries, and the patterns your team avoids. They do not need identical wording, but they should not give conflicting guidance.

Here is the kind of rule file that fits well in .cursor/rules/core.mdc:

---
description: Shared engineering conventions
alwaysApply: true
---

- Node 20+ and TypeScript strict mode
- Prefer async/await over then() chains
- Named exports only
- Tests live beside unit code or in tests/integration for broader flows
- Avoid mutating function arguments
- Explain risky refactors before applying them

---
description: Shared engineering conventions
alwaysApply: true
---

- Node 20+ and TypeScript strict mode
- Prefer async/await over then() chains
- Named exports only
- Tests live beside unit code or in tests/integration for broader flows
- Avoid mutating function arguments
- Explain risky refactors before applying them

When CLAUDE.md and Cursor project rules say the same thing, handoffs are smoother. Claude can do the larger delegated task, and Cursor can keep helping inline without pulling the codebase in a different direction.

What This Unlocks

The biggest thing this workflow changes is the bottleneck of waiting. Anyone who has used an agentic AI tool on a substantial task knows the experience: you kick off a task, and then you sit there watching it work, occasionally nudging it, mostly waiting. That waiting time is expensive. It’s not just the clock — it’s the context-switching cost of re-engaging with your own work once the AI finishes.

Running Claude Code and Cursor in parallel largely eliminates that. The time Claude Code spends on a task becomes productive time in Cursor, not dead time. By the time I come back to review what Claude Code has done, I’ve moved something else forward. The two streams of work interleave rather than queue.

There’s also a quality effect. Because Claude Code is handling the tasks it’s genuinely well-suited to — autonomous, long-horizon, requiring consistent changes across many files — and Cursor is handling the tasks it’s well-suited to — tight feedback loop, in-context suggestions, working with what you have in front of you — neither tool is being asked to do something it does poorly. You’re playing to the strengths of each.

The combined workflow means you’re rarely blocked. Claude Code is working on something in the background. You’re moving forward in Cursor. The bottleneck of “waiting for AI to finish” largely disappears.

It took me longer than I’d like to admit to stop treating these tools as competitors and start treating them as a stack. If you’re currently using one or the other, I’d genuinely encourage you to try both in parallel for a week. The workflow takes a day or two to feel natural, and then it’s hard to go back to the sequential approach.

If you’re new to Claude Code and want to understand what it actually does before diving in, start with What is Claude Code. And if you want to go deeper on getting the most out of it as a standalone tool, the 7 Claude Code Skills post covers the techniques I rely on most.