Start free →

Blog

Cursor Team Rules: how to share Cursor rules with a team

Published: November 6, 2026

Cursor Team Rules are rules a team admin writes once in the Cursor dashboard, and Cursor adds them to Agent for every member, in every repository. They are on Team and Enterprise plans, and an admin can make one required so nobody can turn it off. Every fact below was checked on Cursor's rules docs on 6 November 2026, and the Copilot and Claude Code rows on their own docs the same day.

What are Cursor Team Rules?

One of the four kinds of instructions Cursor reads, next to Project Rules, User Rules and AGENTS.md. The docs call them “Team-wide rules managed from the dashboard.” What sets them apart:

  • Free-form text. A Team Rule is not an .mdc file and does not use the folder structure of Project Rules.
  • Every repository. Cursor puts it in the model context for Agent (Chat) across all repositories and projects of the team.
  • Optional globs. A Team Rule can take a glob pattern to apply only to matching files. Without one, it applies to every conversation.
  • Enforced or not. With “Enforce this rule” on, the rule is required for all team members and cannot be disabled in Customize. A rule that is not enforced can be turned off by each user.
  • Drafts. Leave “Enable” unchecked and the rule is saved as a draft that applies only once you enable it.

Like every Cursor rule, a Team Rule does not reach Cursor Tab. The docs say rules “do not impact Cursor Tab or other AI features.”

Which plan has Team Rules?

Team and Enterprise. On a personal plan you have Project Rules, User Rules and AGENTS.md, which is enough to share most rules through git (next section). What only the dashboard gives you is a rule that reaches every repository at once and that a member cannot switch off.

How do I share Cursor rules with my team without Team Rules?

  • Commit .cursor/rules/. Project Rules are .mdc files under version control, so everyone who clones the repo gets them, and a rule change goes through review like code.
  • Commit AGENTS.md. Cursor reads it in the project root and in subfolders, where the more specific file wins. It is also the one file Codex and Copilot read, and Claude Code can.
  • Use a plugin for rules from another repository. The rules docs say: “To bring rules in from a GitHub repository, package them in a plugin.”
  • Not User Rules. They live in Customize, then Rules, and apply only to you.

Which apply mode each Project Rule should get, and how long it should be, is in our Cursor rules best practices.

Do Team Rules override Project Rules?

Yes. Cursor applies rules in the order Team Rules, then Project Rules, then User Rules. All applicable rules are merged, and “earlier sources take precedence when guidance conflicts.” So when a Project Rule in one repository says the opposite of a Team Rule, the Team Rule wins, and the fix belongs at the team level.

The docs do not say where AGENTS.md sits in that order. They only say a nested AGENTS.md is combined with its parents and the more specific one takes precedence. If a Team Rule and AGENTS.md disagree, Cursor has not published which wins, so do not let them disagree.

Cursor Team Rules vs Copilot and Claude Code org rules

Each of the three has an organization layer. They disagree on whether that layer beats the repository.

Org layerWho wins a conflictWhere it applies
CursorTeam Rules, in the dashboard (Team and Enterprise)The team. Team, then Project, then User; earlier winsAgent in every repo of the team; not Tab
GitHub CopilotOrganization custom instructions (Copilot Business or Enterprise)The person. Personal, then repository, then organization, highest first, in Copilot Chat on GitHub.comSessions on the GitHub website and Copilot code review, not local clients
Claude CodeA managed CLAUDE.md that IT deploys to each machineNot stated. All files are concatenated, the managed one first, and a project instruction is read after itEvery session on that machine; it cannot be excluded with claudeMdExcludes

Sources: Cursor, GitHub (which adds that other clients, VS Code among them, “combine applicable instruction files without defining a general precedence order”), and Claude Code. Claude Code's docs say to use the managed file for guidance and to enforce hard limits with managed settings such as permissions.deny. Cursor makes the same point in its own words: AI guidance “should not be your only security control.”

Two things follow. A rule written as a Cursor Team Rule overrides a repository in Cursor, while the same rule as a Copilot organization instruction yields to it. And none of the three org layers reaches the other two tools. A team that runs Cursor next to Claude Code writes the same rule in two places, and keeps them in sync by hand. What Claude Code shares on its own is in Claude Code team memory.

Do Cursor Team Rules reach Claude Code, Codex or Copilot?

No. They live in Cursor's dashboard and go into Cursor's Agent. Neither do .cursor/rules files. The file all four tools can read is AGENTS.md: Codex and Copilot read it, and Claude Code reads it by default only in a project with no CLAUDE.md (AGENTS.md vs CLAUDE.md has the setup). Skills are a separate question, covered in rules vs skills. And since Cursor removed its Memories feature in 2.1, nothing Cursor learns in a chat is kept for the team either (what happened to Cursor Memories).

How teams keep one set of rules across every agent

Team Rules solve the Cursor half: one place, every repository, no opting out. Two gaps are left. The rule reaches one tool, and somebody still has to write it. Most team rules start as a decision made somewhere else: a review comment, a thread in #eng-payments that settled a webhook retry limit. Harbor is one way to close both: shared memory for AI coding agents. It learns from where your team decides (Slack, pull request reviews, docs and agent sessions), lets you set what waits for a person, and gives Cursor, Claude Code, Codex and GitHub Copilot the rules that apply to each task. To do it by hand instead, see how to share memory and rules across tools.