Cursor + Claude Code: One Workflow, 13 Steps [2026]

Cursor and Claude Code solve two different problems, and most developers who try to pick just one eventually end up frustrated. Cursor is an AI-native editor built for fast, visual, in-context editing. Claude Code is a terminal-based agent built for long-running, repository-wide work: refactors, test suites, multi-file migrations, and Git operations that need to run unattended. As of October 2026, you don’t have to choose. Claude Code ships as a terminal tool that runs inside Cursor’s own integrated terminal, shares the same Model Context Protocol (MCP) servers, and can read the same project instruction files Cursor already uses for its rules.

This tutorial walks through setting up both tools in a single repository, wiring them to share configuration instead of duplicating it, and building a working project where Cursor handles fast iteration while Claude Code handles the heavy lifting. By the end you’ll have a real sample app, a shared MCP server, and a repeatable workflow you can drop into any codebase.

Google · Preferred Sources

Don't miss new tech stories on Google

Add TrendinTech once in the Google app and our stories appear in your news suggestions.

Add Now

Why Combine Cursor and Claude Code Instead of Picking One

The instinct to treat Cursor and Claude Code as rivals makes sense on the surface. Both let you describe a change in plain English and get code back. But they’re optimized for different loops. Cursor’s tab-completion and inline chat are built around a human staring at a diff, accepting or rejecting hunks in real time, with the editor’s own indexing keeping suggestions grounded in the open file. Claude Code is built around delegation: you hand it a task, it plans, edits across dozens of files, runs the test suite, and reports back, all without you watching every keystroke.

Running them together means you stop forcing one tool to do the other’s job. A developer who tries to make Cursor refactor 40 files in one inline chat session will burn tokens and patience. A developer who uses Claude Code for a two-line CSS tweak is swatting a fly with a sledgehammer. The split that works in practice: Cursor for the files you’re actively looking at, Claude Code for the work you’d rather describe once and walk away from.

There’s also a cost argument. Claude Code’s Pro plan runs $17 a month with annual billing ($20 month-to-month) and is pitched by Anthropic’s own product page as suited to short coding sprints in small codebases. The Max plans at $100 or $200 a month bundle matching API credit allowances for teams running agents continuously across larger repositories. Pairing Claude Code’s terminal agent with Cursor’s editor subscription, instead of paying for two separate all-in-one products, is often the cheaper way to get both editing styles.

Prerequisites and Versions You’ll Need

Before starting, confirm you have the following installed. Version mismatches are the single biggest source of “it worked yesterday” bug reports in mixed Cursor/Claude Code setups.

Requirement	Minimum Version	Notes
Node.js	18.x or later	Required to run the sample Express project and the npm-based MCP server
Cursor	Latest stable release channel	Install from cursor.com/docs; auto-updates by default
Claude Code CLI	Latest release from the official changelog	Installed via npm or the standalone installer
Git	2.34+	Claude Code’s auto-commit and diff review features assume a Git repo
Anthropic account	Pro, Max, or Console API key	Pro ($17-$20/mo) covers light use; Max ($100-$200/mo) for continuous agent runs
Operating system	macOS, Linux, or Windows with WSL	Claude Code’s terminal agent runs natively on all three

You’ll also want basic familiarity with the command line, since Claude Code lives in the terminal even when you launch it from inside Cursor. If you’ve never opened Cursor’s integrated terminal (Ctrl+` or Cmd+`), that’s the first thing to practice before step one.

Step 1: Install Cursor and Open a Project

Download Cursor from its official site and install it like any other editor. On first launch, Cursor offers to import your VS Code settings and extensions, which is safe to accept since Cursor is a VS Code fork under the hood. Open or create a folder for the project you’ll use throughout this tutorial — we’ll build a small Express.js API with a Markdown-based task list, simple enough to follow but realistic enough that the Cursor/Claude Code split actually matters.

mkdir cursor-claude-demo && cd cursor-claude-demo
git init
npm init -y
npm install express
cursor .

The last command opens the current directory in Cursor. If `cursor` isn’t on your PATH yet, open Cursor manually and use File > Open Folder instead.

Step 2: Install the Claude Code CLI

Claude Code installs as a standalone CLI, independent of any editor. The source and release history are published on the official Claude Code GitHub repository. Run the install command from Cursor’s integrated terminal so you can confirm immediately that the terminal and the CLI play nicely together.

npm install -g @anthropic-ai/claude-code
claude --version

If the install fails with a permissions error on macOS or Linux, don’t reach for `sudo` as a first move — it’s a common pitfall covered later in this guide. Instead, fix your npm global prefix so it points somewhere your user account owns.

Once installed, authenticate. Claude Code supports logging in with a Claude.ai subscription (Pro or Max) or with an Anthropic Console API key for pay-as-you-go billing:

claude
# Follow the interactive prompt to authenticate with your Claude account,
# or export ANTHROPIC_API_KEY=sk-ant-... for Console billing

On Pro, Max, and Team plans, Claude Code runs in what Anthropic calls auto mode by default — it executes safe, low-risk actions without stopping to ask, while still flagging genuinely risky commands like destructive deletes or force-pushes for manual confirmation.

Step 3: Pick the Right Model for Each Tool

As of October 2026, Anthropic’s current Claude Code defaults, documented in the official Claude Code changelog, are Claude Opus 5.5 (`claude-opus-5-5`) for the heaviest agentic coding and knowledge work, and Claude Haiku 5.5 (`claude-haiku-5-5`) — released in early October 2026 — as the default fast, low-cost model for high-volume tasks. Opus 5.5 ships with a 1-million-token context window, 128,000 maximum output tokens, and always-on adaptive thinking, priced at $4 per million input tokens and $20 per million output tokens, with cache reads at $0.20 per million tokens. Claude Haiku 5.5 carries the same 1-million-token context window at a fraction of the cost: $0.10 per million input tokens and $0.50 per million output tokens for prompts under 100,000 tokens.

Claude Sonnet 5.5 is the default Sonnet-tier model in Claude Code, also with a 1-million-token context window, priced at $2 per million input tokens and $10 per million output tokens — generally the best balance for day-to-day repository work that’s heavier than a quick fix but doesn’t need Opus-level reasoning.

Cursor, meanwhile, lets you select the model powering its own inline chat and tab completion separately from whatever Claude Code uses in the terminal — the two are independent settings. Cursor’s own release notes describe recent support for larger Claude context windows and fast-mode variants in its model picker, so check Cursor’s model dropdown (bottom of the chat panel) against Anthropic’s current lineup before assuming you’re on the latest option.

Model	Context Window	Input / Output Price (per MTok)	Best Used For
Claude Opus 5.5	1M tokens	$4 / $20	Long-running agentic coding, complex refactors in Claude Code
Claude Sonnet 5.5	1M tokens	$2 / $10	Everyday feature work, default day-to-day driver
Claude Haiku 5.5	1M tokens	$0.10 / $0.50	High-volume, low-cost tasks: linting, simple edits, quick lookups

A practical rule for this tutorial’s project: use Haiku 5.5 or Sonnet 5.5 inside Cursor for inline edits, and reserve Opus 5.5 in Claude Code’s terminal session for the multi-file task you’ll run in Step 9. Mixing model tiers deliberately, rather than always defaulting to the most expensive option, is the difference between a $20 Claude Code bill and a $200 one at the end of the month.

Step 4: Create a Shared Project Instruction File

The biggest source of drift between Cursor and Claude Code is having two separate sets of “house rules” — one in Cursor’s rules files, one buried in ad hoc Claude Code prompts. Fix that by creating a single `CLAUDE.md` file at your repository root. Claude Code reads this automatically at the start of every session, and you can point Cursor’s rules at the same file so both tools follow identical conventions.

# CLAUDE.md
## Project conventions
- Use CommonJS (require/module.exports), not ESM, in this repo.
- All routes live in /routes, one file per resource.
- Run `npm test` before reporting any task as complete.
- Never edit files in /legacy without explicit confirmation.
- Commit messages: imperative mood, under 72 characters on the first line.

In Cursor, create a matching rule under Settings > Rules that simply references the same conventions (Cursor’s own rules format is YAML-frontmatter Markdown under `.cursor/rules/`), so a developer editing a file in Cursor’s chat panel sees the same constraints Claude Code enforces in the terminal. Keeping the source of truth in `CLAUDE.md` and mirroring it into `.cursor/rules/` — rather than writing two independent rule sets — is what actually prevents the tools from contradicting each other three weeks into a project.

Step 5: Set Up a Shared MCP Server

The Model Context Protocol (MCP) is what lets both Cursor and Claude Code call out to the same external tools — a database, a ticketing system, a search index — using one configuration instead of two. Claude Code’s own MCP documentation describes it discovering servers from several locations: the project’s `.mcp.json`, the user-level `~/.claude.json`, installed plugins, and any Claude.ai connectors you’ve authorized. Cursor reads project-scoped MCP servers from the same kind of `.mcp.json` file, and its October 2026 release notes specifically call out more reliable OAuth handling for MCP servers that reject unusual redirect URLs or require repeated re-authentication.

Create `.mcp.json` at the repository root so it’s committed to Git and shared across both tools and across your team:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    }
  }
}

Never commit the actual token — use an environment variable reference or a `.env` file excluded via `.gitignore`. With this file in place, both Cursor’s MCP settings panel and Claude Code’s `/mcp` command should list the same two servers, confirming they’re reading from one shared config instead of drifting apart.

Step 6: Verify the MCP Connection in Claude Code

From Cursor’s integrated terminal, launch Claude Code in the project directory and check that it sees the MCP servers you just defined:

claude
/mcp

The `/mcp` command shows every server discovered from `.mcp.json`, `~/.claude.json`, plugins, and connectors, each with live connection status plus Connect, Reconnect, and Re-authenticate actions inline. If a server shows as disconnected, re-run the Reconnect action before troubleshooting anything else — most “it’s not working” reports at this stage are a stale OAuth token, not a config error.

Step 7: Verify the Same MCP Servers in Cursor

Switch to Cursor’s own settings (Settings > MCP) and confirm the identical server list appears there. Cursor’s agent now exposes all tools, prompts, and resources from MCP servers that paginate their responses, which matters once you connect larger servers (like a full GitHub integration) that return more tools than fit in a single response — earlier versions of Cursor’s agent could silently truncate that list and miss tools.

If Cursor shows fewer tools than Claude Code’s `/mcp` output for the same server, update Cursor to the latest release before debugging further — pagination handling for MCP tool lists is a documented recent fix, not a configuration issue you can resolve from your end.

Step 8: Build the Sample Project’s First Feature in Cursor

Now put the editor-side tool to work on something it’s good at: a quick, visible, single-file feature. Open `index.js` in Cursor and use inline chat (Cmd/Ctrl+K) to describe a simple Express server:

const express = require('express');
const app = express();
app.use(express.json());

app.get('/tasks', (req, res) => {
  res.json({ tasks: [] });
});

app.listen(3000, () => console.log('Server running on port 3000'));

This is the kind of change where Cursor’s tight feedback loop wins: you see the diff inline, accept it, run the file, and iterate in seconds. Save it, run `node index.js`, and confirm `curl localhost:3000/tasks` returns `{“tasks”:[]}`. This single endpoint is the seed the next step grows into a full feature with persistence, validation, and tests — exactly the kind of multi-file expansion better suited to a delegated agent than a chat window.

Step 9: Delegate the Multi-File Build-Out to Claude Code

With the skeleton in place, switch to Cursor’s terminal and hand the expansion to Claude Code. This is the step that demonstrates the actual value of the pairing: a task description that would take several rounds of inline chat edits in Cursor, handled in one delegated session.

claude "Add full CRUD routes for /tasks backed by a JSON file store
in /data/tasks.json. Include POST, GET by id, PUT, and DELETE.
Add input validation for the task title and status fields.
Write Jest tests for every route in /tests/tasks.test.js.
Run the test suite when you're done and fix any failures."

Claude Code will plan the change, create the new route file, the JSON-backed store module, the test file, install Jest if it’s missing, and run the suite — all while respecting the conventions you set in `CLAUDE.md` back in Step 4. Because Claude Code supports self-hosted environments in public beta, teams with stricter network policies can also run these sessions on infrastructure inside their own organization rather than relying solely on Anthropic’s hosted execution.

Watch for Claude Code’s plan output before it starts editing. If something in the plan looks wrong — it’s about to touch `/legacy`, for instance, which you explicitly fenced off in `CLAUDE.md` — interrupt with Escape and redirect before it writes a single file.

Step 10: Review the Agent’s Diff Back in Cursor

Once Claude Code finishes, don’t just trust the green checkmarks — switch back to Cursor and open the Source Control panel to review every changed file as a diff, the same way you’d review a teammate’s pull request. This is the step most tutorials skip, and it’s the one that actually catches problems: an agent that reports “tests passing” after quietly weakening an assertion is a real failure mode, not a hypothetical one.

Use Cursor’s inline chat on any file you want adjusted before committing — this is the natural handoff point, where Claude Code did the bulk delegated work and Cursor does the fine-grained human review and polish.

Step 11: Commit Through Claude Code’s Git Integration

Claude Code can stage, commit, and even open pull requests directly, following the commit-message conventions from your `CLAUDE.md`. From the terminal:

claude "Stage the new task routes, store, and tests, then commit
with a message following our CLAUDE.md conventions."

Claude Code is described in Anthropic’s own documentation as catching risky commands even in auto mode, so a force-push or a hard reset will still prompt for confirmation rather than executing silently. That’s the safety net that makes delegating Git operations to an agent tolerable in a shared repository.

Step 12: Set Up Claude Code Projects for Ongoing Work

For work that spans more than one sitting, Claude Code supports projects, which group related coding sessions together and can be supervised from Claude Code Desktop across multiple concurrent agents. If you’re running several feature branches in parallel — one Claude Code session hardening the task API, another adding authentication — grouping them as a project keeps the context and history organized instead of scattered across terminal scrollback you’ll never find again.

Step 13: Lock Down Permissions Before You Scale Up

Before handing Claude Code bigger, less-supervised tasks, spend five minutes on permission boundaries. In the project’s `.claude/settings.json`, explicitly allow the commands you expect (test runners, linters, the package manager) and deny the ones you don’t (arbitrary network calls, destructive filesystem operations). Pair that with restricting the GitHub token in your `.mcp.json` to the single repository it needs, not your entire account. Five minutes here is what separates an agent that occasionally asks before touching something sensitive from an agent that technically could, and once did, touch something it shouldn’t have.

Common Pitfalls When Combining Cursor and Claude Code

Running two different model tiers without noticing. Cursor’s chat model and Claude Code’s terminal model are configured separately. It’s easy to run expensive Opus 5.5 in both without meaning to, doubling your spend for no quality gain on the Cursor side.
Duplicating rules instead of sharing them. Writing separate instructions in `.cursor/rules/` and ad hoc Claude Code prompts guarantees the two tools eventually contradict each other. Centralize in `CLAUDE.md` and mirror it, as described in Step 4.
Installing the CLI with `sudo npm install -g`. This creates root-owned files in your global npm directory that break future updates. Fix your npm prefix instead of reaching for `sudo` on every install.
Committing the `.mcp.json` file with real tokens inline. Always reference environment variables; a leaked GitHub personal access token in Git history is a cleanup headache that’s entirely avoidable.
Letting Claude Code run unattended on a repo with no `.claude/settings.json` permissions configured. Auto mode is convenient, but without explicit allow/deny rules you’re trusting default behavior on every project, not just the ones you’ve reviewed.
Assuming Cursor and Claude Code see identical MCP tool lists. Pagination and OAuth handling differ by version — verify both tools’ `/mcp` and MCP settings panel show the same servers rather than assuming parity.
Skipping the diff review step because “the tests passed.” Passing tests don’t guarantee correct tests. Step 10 exists because agent-written test suites can pass while quietly asserting the wrong thing.
Forgetting which plan you’re on when the bill arrives. Claude Code’s Max plans include API credits bundled into the $100 or $200 monthly price; exceeding that bundled allowance switches you to metered billing, which can surprise teams running several agents continuously.

Expected Output at Each Major Milestone

Here’s what success looks like at the key checkpoints in this tutorial, so you can confirm you’re on track before moving to the next step.

# After Step 2 (claude --version)
Claude Code CLI v... (version string will match the latest release)

# After Step 6 (/mcp inside Claude Code)
MCP servers:
  filesystem  [connected]
  github      [connected]

# After Step 9 (Claude Code CRUD delegation)
Running test suite...
PASS tests/tasks.test.js
  (check) POST /tasks creates a task
  (check) GET /tasks/:id returns a task
  (check) PUT /tasks/:id updates a task
  (check) DELETE /tasks/:id removes a task
Tests: 4 passed, 4 total

If your output diverges meaningfully from this — particularly zero tests collected, or MCP servers stuck on a “connecting” state — stop and check the relevant troubleshooting entry below before continuing further into the workflow.

Troubleshooting Guide

`claude: command not found` after installing. Your global npm bin directory isn’t on PATH. Run `npm config get prefix` and add `<prefix>/bin` to your shell’s PATH, then restart the terminal (including Cursor’s integrated one, which may need a full editor restart to pick up PATH changes).
Claude Code authenticates but immediately logs out. This usually means a system clock skew issue affecting token validation. Confirm your system time is synced, then re-run `claude` and re-authenticate.
`/mcp` shows a server as “disconnected” that worked yesterday. OAuth tokens for MCP servers expire. Use the Reconnect or Re-authenticate action directly from the `/mcp` panel rather than deleting and recreating the server entry.
Cursor’s MCP panel shows fewer tools than Claude Code’s `/mcp` output. This is a known gap in older Cursor builds around paginated MCP tool responses. Update Cursor to the latest release; it’s a documented fix, not a local config problem.
Claude Code keeps proposing changes to files listed as off-limits in `CLAUDE.md`. Check that `CLAUDE.md` sits at the repository root, not a subdirectory — Claude Code only auto-loads it from the top level and nested parent directories.
Jest tests fail with “Cannot find module” right after Claude Code says the suite passed. This means the agent ran tests in a stale `node_modules` state before a fresh install completed. Re-run `npm install && npm test` manually to confirm, and ask Claude Code to re-verify in a fresh shell.
Cursor’s inline chat ignores your `.cursor/rules/` file. Rules files need valid YAML frontmatter with a `description` field and either an `alwaysApply: true` flag or a glob pattern matching the open file — a missing frontmatter block makes Cursor silently skip the rule.
Claude Code’s terminal session hangs on a permission prompt you can’t see. This happens when the prompt scrolled out of Cursor’s terminal pane. Resize the terminal pane taller, or run `claude` in a standalone terminal window instead of Cursor’s embedded one for long sessions.
GitHub MCP server returns 401 errors mid-session. Your personal access token likely expired or lacks the `repo` scope. Regenerate it on GitHub with the correct scopes and update the environment variable referenced in `.mcp.json`.

Advanced Tips for Daily Use

Once the basic workflow is solid, a few refinements make it noticeably smoother for daily work. First, use Claude Code’s project grouping (Step 12) to keep long-running feature branches separate from quick one-off fixes — mixing them in one session’s context tends to produce plans that reference work you’ve already shipped elsewhere. Second, default to Sonnet 5.5 for Claude Code’s everyday driver and reserve Opus 5.5 specifically for tasks involving unfamiliar codebases or ambiguous specs, where the extra reasoning budget earns back its cost; routine, well-specified tasks rarely need it.

Third, if your team shares MCP servers across repositories, Cursor’s team marketplace functionality distributes those servers across cloud agents, the IDE, and the CLI from one managed source — worth setting up once a second or third repository adopts the same pairing, rather than re-authoring `.mcp.json` by hand in every repo. Fourth, lean on Cursor’s newer review bots for post-merge health checks and PR-level exploit hunting as a second layer of review sitting after your own diff check in Step 10, not as a replacement for it — automated review bots catch different classes of problems than a human skimming a diff, and running both costs little beyond the time to read two reports instead of one.

Finally, treat `CLAUDE.md` as a living document. Every time Claude Code does something technically correct but not what you wanted, that’s a signal to add a line to `CLAUDE.md` rather than just fixing it in the moment — the next session, and the next developer on the team, benefit from the same correction being encoded once instead of repeated as a verbal habit.

Security Considerations for Shared MCP Configurations

Because `.mcp.json` is typically committed to the repository so both Cursor and Claude Code (and every teammate) can read it, treat it the same way you’d treat any other piece of infrastructure-as-code: no secrets committed directly, scoped tokens rather than account-wide ones, and a review process for anyone adding a new MCP server to the shared config. A filesystem MCP server scoped to the project directory is low-risk. A server with broad API access to production systems is not something to add casually just because an agent asked for it mid-task — require the same change-review discipline you’d apply to a new production credential anywhere else.

It’s also worth auditing `.claude/settings.json` periodically, especially after onboarding a new project or MCP server, to confirm the allow/deny lists from Step 13 still match what the project actually needs — permissions configured for an early prototype rarely stay appropriate once the same repo starts touching real user data.

Complete Working Project Recap

By following all 13 steps, you’ve built a small but complete Express.js task API with the following pieces, each attributable to the tool best suited for it:

Component	Built With	Why
Initial server skeleton (index.js)	Cursor inline chat	Single-file, visible, fast iteration
Full CRUD routes + JSON store	Claude Code delegated session	Multi-file, repeatable pattern, no need to watch each edit
Jest test suite	Claude Code delegated session	Generated and self-verified in the same pass as the routes
Shared rules (CLAUDE.md + .cursor/rules/)	Both tools, one source of truth	Prevents the two tools from contradicting each other
MCP servers (.mcp.json)	Both tools, shared config	Filesystem and GitHub access available identically to both
Final commit	Claude Code Git integration	Commit message follows CLAUDE.md conventions automatically

This project is intentionally small enough to finish in under an hour, but the pattern — Cursor for the visible work, Claude Code for the delegated work, one shared rules file and one shared MCP config tying them together — scales to codebases far larger than this tutorial’s sample API.

Real-World Scenario: Fixing a Production Bug With Both Tools

The sample project in this tutorial is deliberately small, so it’s worth walking through how the same Cursor-plus-Claude-Code pattern plays out on an actual production incident, where the stakes and the file count are both higher. Say a bug report comes in: the `/tasks` endpoint occasionally returns a 500 error under load, and nobody’s sure why. This is the kind of ambiguous, multi-step investigation where the two tools’ different strengths become obvious fast.

Start in Claude Code, not Cursor, because the first job is investigation across the whole codebase, not editing a known file. From the terminal:

claude "We're seeing intermittent 500 errors on GET /tasks under load.
Search the routes, the JSON store module, and recent commits for
anything that could cause a race condition on concurrent reads/writes.
Don't change anything yet -- report back with a root-cause hypothesis."

Because Claude Code has the full 1-million-token context window of Opus 5.5 available, it can hold the entire routes directory, the store module, and recent Git log output in context simultaneously, rather than you manually opening and closing files trying to spot the pattern yourself. In a repository this size that search takes seconds; in a repository with hundreds of files, it’s the difference between an hour of manual grepping and a two-minute delegated investigation.

Once Claude Code reports back with a hypothesis — say, the JSON file store has no write lock, so two concurrent requests can corrupt the file mid-write — that’s the moment to switch to Cursor. The fix itself is usually small and contained to one or two files, exactly the kind of change where watching the diff in real time matters more than delegating it blind. Open the store module in Cursor, use inline chat to add a write queue or a file lock, and step through the resulting diff line by line before accepting it, since concurrency fixes are exactly the category of change where a subtly wrong implementation can look correct and still fail under the next load spike.

With the fix in place, hand verification back to Claude Code rather than trusting a single manual test run:

claude "Write a load test that fires 50 concurrent POST and GET
requests at /tasks and confirms no data corruption or dropped
writes. Run it against the current code and report results."

This three-part pattern — Claude Code investigates broadly, Cursor edits narrowly with human eyes on the diff, Claude Code verifies with a test an engineer might not have thought to write under time pressure — is the same shape as the CRUD build-out from Steps 8 through 10, just applied to debugging instead of greenfield feature work. Once you’ve run it a few times, deciding which tool opens first for a given task stops being a conscious decision and just becomes how the repository works.

Frequently Asked Questions

Can I use Claude Code inside Cursor without any special configuration?

Yes. Claude Code is a standalone CLI, so it runs in Cursor’s integrated terminal exactly as it would in any other terminal, with no special integration required beyond installing and authenticating it. The shared `CLAUDE.md` and `.mcp.json` setup in this tutorial is optional but strongly recommended once you move past casual use.

Do Cursor and Claude Code use the same Claude model by default?

Not necessarily. Claude Code’s defaults as of October 2026 are Claude Opus 5.5 for heavy agentic work and Claude Sonnet 5.5 for everyday tasks, while Cursor lets you pick a model independently in its own chat settings. Always check both configurations rather than assuming they match.

Is it worth paying for both a Cursor subscription and a Claude Code plan?

For most individual developers, yes, if you genuinely use both editing styles. Claude Code’s Pro-tier access starts at $17 a month with annual billing, which is a modest add-on to an existing Cursor subscription, and the Max plans ($100 or $200 a month with bundled API credits) are aimed at heavier, team-level agent usage rather than casual use.

What happens if Cursor and Claude Code disagree on coding conventions?

This happens when rules are duplicated rather than shared, and it’s one of the most common pitfalls in mixed setups. The fix in this tutorial is to keep one `CLAUDE.md` file as the source of truth and mirror its conventions into Cursor’s `.cursor/rules/` directory, rather than writing separate instructions for each tool.

Can Claude Code and Cursor share the same MCP servers?

Yes. Both tools read project-scoped MCP servers from a shared `.mcp.json` file at the repository root. Claude Code also checks `~/.claude.json`, plugins, and Claude.ai connectors, so its server list can be a superset of what’s defined in the project file alone.

Is Claude Code safe to run with full auto mode enabled?

Auto mode handles routine, low-risk actions without stopping for confirmation, but Anthropic’s documentation describes it as still flagging risky commands for manual approval. Combine it with explicit allow/deny rules in `.claude/settings.json`, as described in Step 13, rather than relying on default behavior alone in any repository with production access.

Does this workflow work on Windows?

Yes, through WSL. Both Cursor and the Claude Code CLI run natively inside a WSL environment, and Cursor’s integrated terminal can be configured to default to a WSL shell, keeping the entire workflow in this tutorial consistent across macOS, Linux, and Windows.

Can multiple Claude Code sessions run at once on different features?

Yes. Claude Code’s project feature groups related sessions and can be supervised from Claude Code Desktop, which supports monitoring multiple concurrent agent sessions working on different parts of the same or related codebases.

Cursor + Claude Code: Build One Workflow in 13 Steps [2026]