Cursor for Teams

Quick answer

Cursor Business costs $40 per user per month and adds admin controls, SSO, privacy-mode enforcement, and usage analytics. Commit .cursor/rules/ and .cursor/mcp.json to your repo so every engineer gets the same rules and integrations on pull. Keep personal settings in ~/.cursor/. Onboard a new hire in under an hour: install Cursor, import VS Code settings, clone the repo, verify project config loaded, assign a model tier. Admins can see seat usage and enforce privacy from the dashboard at cursor.com.

What the Business plan actually gives you

Cursor Business is $40 per user per month. Compared with Pro at $20 the extras are:

• Centralised billing through one invoice per org, not per seat.
• SAML SSO and SCIM provisioning for identity management.
• Privacy mode enforced at the org level so no data leaves the tenant.
• Admin dashboard with seat management, usage analytics, and model spend.
• Priority support with faster response times than the Pro tier.
• Role-based admin controls for who can invite new seats and change billing.

For small teams the pitch is simple: billing headache removed and data handling guaranteed. For larger orgs the SSO and SCIM integration is usually the deciding factor.

Project rules vs personal rules

Cursor reads two kinds of rules. Personal rules live in ~/.cursor/rules/ and apply to every project on a given machine. Project rules live in .cursor/rules/ at the workspace root and apply only when that repo is open.

For team rollout, most rules belong in the project directory. Commit them to git. Every engineer who clones the repo inherits the rules on their first pull. No installation step, no extra config.

A minimal .cursor/rules/ setup for a typical team:

• coding-conventions.mdc: naming rules, import order, preferred libraries.
• testing.mdc: test framework, fixture patterns, where to put test files.
• safety.mdc: forbidden shell commands and data-access rules.
• design-system.mdc: pointer to the design token file and UI component folder.

Keep each rule file short (under 20 lines). Long rule files are respected less reliably than short focused ones.

Sharing MCP configuration

The same pattern works for MCP servers. Put .cursor/mcp.json at the repo root with the servers the team should use: GitHub, Postgres (pointed at a shared dev database), Supabase, internal docs.

Keep secrets out of the committed file. Reference env variables and have engineers supply their own tokens through a gitignored .env or their personal ~/.cursor/mcp.json.

An example project mcp.json that ships to the team:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PAT}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres", "${DB_URL}"]
    }
  }
}

Each engineer sets the env vars locally. The committed file is free of secrets.

Separating personal and team config

The mental split that keeps things tidy:

• ~/.cursor/ is personal. Keybindings, model preferences, personal rules, personal MCP tokens.
• .cursor/ in the repo is team-shared. Rules everyone should follow, MCP servers everyone should have, shared Notepad templates.

If a setting feels both personal and team-shared, default to personal and document the pattern in team docs. It is easier to pull a personal setting up to team than to untangle a team setting someone wants to override.

A new-hire onboarding checklist

A checklist a new engineer can run through in an hour on day one:

1. Download Cursor from cursor.com and install.
2. Sign in with the company Cursor account (SSO if Business plan is configured).
3. On first launch, accept the VS Code settings import if they had VS Code installed.
4. Clone the main repo and open it in Cursor.
5. Confirm .cursor/rules/ and .cursor/mcp.json are present and Cursor picked them up.
6. Set personal env variables for any MCP servers that need tokens.
7. In Settings > Models, confirm the default model matches the team policy.
8. Open Composer on a small task to verify the agent runs.
9. Join the team Cursor Slack channel or whatever the team uses for questions.

This routine gets a new hire productive before lunch.

Team model policy

With many models available, picking which ones the team uses matters for cost and consistency. A reasonable default policy:

• Tab autocomplete: Cursor Small or another fast low-cost model. Typing speed is the priority.
• Cmd+K inline edits: Claude Sonnet or GPT-4o. A good balance of speed and quality for small changes.
• Composer agent: Claude Sonnet as the default, Opus reserved for genuinely hard tasks.
• Chat for questions: whichever model the engineer prefers. Low stakes, no enforcement needed.

Write the policy in a team rule file so the expectations are visible. The actual model selection still happens per-engineer in Settings, but having a written default cuts down on ad-hoc choices.

The admin dashboard

Cursor Business org owners see a dashboard at cursor.com with:

• Active seat count and billing for the current period.
• Usage analytics: premium requests per engineer, most-used models, daily active users.
• Seat management: invite, remove, transfer seats between engineers.
• SSO configuration: SAML setup for the identity provider.
• Privacy settings: org-wide enforcement of no-training mode.

Check the dashboard weekly for the first month of a rollout. You find out quickly which engineers are active, which are stuck, and whether the total spend tracks the budget.

Security and privacy settings

Two settings matter most for sensitive codebases:

• Privacy mode: toggled on forces Cursor to send prompts and code to model providers with a no-training-data-retention contract. On Business this can be enforced org-wide.
• Disable codebase indexing: if your security policy forbids any code embeddings leaving a machine, this turns off the @Codebase feature. Trade-off: agent quality drops because context retrieval gets weaker.

For regulated environments, talk to Cursor Sales about the Enterprise contract which adds data-residency options.

Migrating from GitHub Copilot

Teams moving from Copilot to Cursor typically follow this path:

1. Pick a pilot team of 5 to 10 engineers.
2. Run both tools in parallel for two weeks. The pilot team expenses the $20 Pro plan personally; the company reimburses later.
3. Collect feedback: what did Cursor do better, what did it do worse, which tasks changed.
4. If the pilot approves, move the whole engineering org onto Cursor Business over a month.
5. Cancel the team Copilot licence at the end of the billing cycle.

The parallel-use phase catches the real blockers. Common surprises: teams that rely on Copilot's GitHub.com PR reviews need a plan, and JetBrains users are a non-starter because Cursor does not work there.

Shared Notepads and documentation

Notepads sit inside the workspace so committing them shares them with the team. A few patterns that work:

• Design tokens Notepad: colors, spacing, font stack. Used in every UI task.
• API reference Notepad: key endpoints, auth flow, common request shapes.
• Prompt templates Notepad: the three or four prompts the team uses weekly.

Notepads are a Cursor feature rather than a generic markdown file, but you can also just commit plain markdown docs to the repo and reference them with @File in Composer. For team onboarding docs, plain markdown is usually easier than a Notepad because it opens in any editor.

Code review workflow

A pattern many teams adopt after rolling out Cursor:

1. Engineer makes changes, commits, and opens a PR in the usual way.
2. Before requesting review, the engineer runs Composer against the diff with a prompt like review this diff as if you were a senior engineer.
3. Composer flags risks, test gaps, naming inconsistencies.
4. The engineer addresses the easy ones and pushes a cleanup commit.
5. Human reviewers now spend time on architecture and design choices rather than typos.

This shaves review cycles by about 25% in teams that have tracked it. Not magic, but a meaningful lift.

Training and adoption

Getting a skeptical team to actually use Cursor requires more than a licence. Three habits that help:

• Host a weekly tip exchange: 15-minute meeting where each engineer shares one Cursor trick they used that week.
• Keep a shared rules file as a living doc: when someone finds a pattern that worked, add it to .cursor/rules/ so everyone benefits.
• Highlight wins in standup: if Composer saved an engineer two hours on a refactor, say so. Adoption follows visible results, not licence purchases.

Most teams hit real productivity gains by week four of a rollout. The first three weeks are learning the tool and shaping the shared configuration. After that, the tool starts paying for itself.

A 30-day rollout plan

A compressed month-long plan an engineering manager can run:

1. Week 1: pilot group of 5 gets Pro licences, installs Cursor, commits initial .cursor/rules/.
2. Week 2: pilot group uses Cursor as primary editor; collect feedback daily.
3. Week 3: upgrade to Business plan, set up SSO, expand to full engineering team.
4. Week 4: run the weekly tip exchange, track analytics, close the Copilot subscription if applicable.

By day 30 the team has a working shared config, an active tip culture, and real billing data to judge the ROI.