How to set up Cursor for Salesforce development

Cursor is a code editor built on VS Code, with AI built in. Out of the box, it knows Apex and JavaScript well. It doesn't know your org, your naming rules or how your team builds things. This guide walks you through a setup that fixes that, step by step. It takes about an hour for one developer.

You'll need a Salesforce sandbox or Developer Edition org, admin rights on your laptop, and a Cursor account.

Step 1: Install Cursor and the Salesforce extensions

Download Cursor from cursor.com and install it. If you already use VS Code, Cursor can import your settings and themes when it first opens.

Next, open the Extensions panel (Ctrl+Shift+X, or Cmd+Shift+X on a Mac) and install the Salesforce Extension Pack. This gives you Apex language support, the Apex Replay Debugger, Lightning Web Components support and SOQL tools.

• Cursor gets extensions from the Open VSX registry, not the Microsoft Marketplace. Before you install, check that the publisher is Salesforce.
• If you don't see the Extensions panel, you may be in Cursor's agent-focused window. Switch to the classic editor window to manage extensions.

Step 2: Install the Salesforce CLI

The Salesforce CLI (sf) is how both you and the AI talk to your org. Install it from the Salesforce CLI page on developer.salesforce.com, then check it works:

sf --version

If the command isn't found, close and reopen Cursor so it picks up the new path.

Step 3: Open a Salesforce DX project

If your team already keeps metadata in Git, clone that repository and open the folder in Cursor. If you're starting fresh, create a project:

sf project generate --name my-salesforce-project

Open the new folder in Cursor. You'll see force-app, manifest and sfdx-project.json. Those tell the Salesforce extensions and the AI that this is a Salesforce project.

Step 4: Connect a sandbox, not production

Log in to a sandbox and give it a short alias:

sf org login web --alias dev-sandbox --instance-url https://test.salesforce.com --set-default

Your browser opens so you can log in. When you're done, check the connection:

sf org list

Use a sandbox or a Developer Edition org for everything in this guide. The AI can run CLI commands for you, so keep production out of reach. Don't log in to production on the same machine profile unless your team has agreed rules for it.

Step 5: Pull your org's metadata into the project

The AI writes better code when it can see what's already in your org: your objects, fields, classes and Flows. Retrieve them with a manifest:

sf project retrieve start --manifest manifest/package.xml

Edit manifest/package.xml first so it lists the metadata types you work with, like ApexClass, ApexTrigger, CustomObject, Flow and LightningComponentBundle. Now when you ask Cursor to add logic to the Account trigger, it can read the trigger handler you already have instead of inventing a new one.

Step 6: Add project rules for your standards

This is the step most teams skip, and it's the one that makes the biggest difference. Project rules are short instructions that Cursor reads before it writes code. They live in your repository in .cursor/rules, as .mdc files, so everyone on the team gets the same rules.

Here's a simple example for Apex. Save it as .cursor/rules/apex-standards.mdc:

---
description: Apex coding standards for this org
globs: force-app/**/*.cls, force-app/**/*.trigger
alwaysApply: false
---
- One trigger per object. Put logic in a handler class, never in the trigger.
- Bulkify everything. No SOQL queries or DML statements inside loops.
- Run queries in user mode: use WITH USER_MODE or AccessLevel.USER_MODE.
- Declare "with sharing" or "inherited sharing" on every class.
- Never hard-code record IDs. Use Custom Metadata for configuration.
- Every class needs a test class named ClassName_Test, with bulk,
  negative and permission tests. Use the shared TestDataFactory.

Start small. Write down the five or six rules your reviewers comment on most often, then add more as you go. Older guides mention a single .cursorrules file in the project root. That still works in many versions, but the .cursor/rules folder is the current approach and lets you have separate rules for Apex, LWC and Flows.

Step 7: Keep sensitive files out of the AI's view

Add a .cursorignore file to the project root, listing anything the AI shouldn't read, such as files with credentials, data exports or .env files. Then check your Cursor settings with your security team. Turn on privacy mode if your company requires it, and agree which AI models people can use.

Remember that the AI sees whatever is in your project. That's one more reason to work in a sandbox with test data, not real customer data.

Step 8: Connect the Salesforce DX MCP server (optional)

Salesforce publishes a Salesforce DX MCP server that lets Cursor's agent use Salesforce tools directly, like listing orgs, querying data or deploying metadata. It's in beta, so check the latest instructions on developer.salesforce.com before you use it. You add it to Cursor's mcp.json file with an entry like this:

{
  "mcpServers": {
    "Salesforce DX": {
      "command": "npx",
      "args": ["-y", "@salesforce/mcp@latest",
               "--orgs", "dev-sandbox",
               "--toolsets", "orgs,metadata,data"]
    }
  }
}

Point --orgs at your sandbox alias, and only turn on the toolsets you need. You'll need Node.js installed for this step.

Step 9: Try it on a small story

Pick a small, real story from your backlog, like adding a validation to a trigger handler. Ask Cursor to make the change, then check that it:

• Followed your rules: the handler pattern, user mode queries and sharing.
• Wrote a test class with bulk, negative and permission tests.
• Didn't use fields or objects that don't exist in your org.

Before you deploy, do a check-only deployment to the sandbox to catch errors early:

sf project deploy start --source-dir force-app --dry-run

If something isn't right, don't just fix the code. Add a rule so it doesn't happen again. That's how the setup gets better every sprint.

Setting it up for a whole team

Doing this for one developer takes an hour. Doing it well for a team takes more planning. Everyone needs the same extensions, rules and settings. Your security team needs to approve what the AI can access. The rules need an owner who keeps them up to date. And the setup works best when it's connected to Jira and your DevOps pipeline, so stories and reviews flow through it too. Our article on what a proper AI delivery setup includes covers the full picture.

Questions teams ask

Does Cursor work with the Salesforce Extension Pack?

Yes. Cursor is built on VS Code and installs extensions from the Open VSX registry. Install the Salesforce Extension Pack from the Extensions panel and check that the publisher is Salesforce.

Should Cursor connect to a production org?

No. Connect Cursor and the Salesforce CLI to a sandbox or Developer Edition org. The AI can run CLI commands, so keeping production out of reach is the safest setup.

Where do Cursor project rules go?

In the .cursor/rules folder in your repository, as .mdc files. Commit them to Git so every developer on the team gets the same rules.

Do I need the Salesforce DX MCP server?

No, it's optional. Cursor works well with the Salesforce CLI and extensions alone. The MCP server lets the AI agent use Salesforce tools directly, but it's in beta, so check the latest documentation first.