Cursor Global User Rules: Where ~/.cursor/rules Lives (and When AlwaysApply Matters)
Confused about Cursor global vs project rules? Here's the exact home-directory path on Mac and Windows, how AlwaysApply works, and when to use user rules vs .cursor/rules in the repo.
Cursor global user rules are the rules that should follow you across every project — not the conventions that belong in a single repo. If you put personal preferences in .cursor/rules inside a repository, teammates inherit them (or you lose them when you switch machines). If you put team conventions only in your home directory, the next engineer never sees them.
This guide covers where ~/.cursor/rules lives on Mac and Windows, how that differs from project rules, and when alwaysApply matters. It is the companion to Cursor not following rules.
Project rules vs global user rules
| Type | Typical path | Who sees it | Best for |
|---|---|---|---|
| Project rules | .cursor/rules/ in the repo | Everyone who clones the repo | Team conventions, stack-specific patterns |
| Global user rules | ~/.cursor/rules (home directory) | Only your Cursor install | Personal preferences across all projects |
Mixing these up is a common reason people think Cursor “ignores” rules: they edited the global file while debugging a project-only path — or the reverse.
Where ~/.cursor/rules lives
macOS / Linux
~/.cursor/rules/
# expands to something like:
# /Users/you/.cursor/rules/Windows
%USERPROFILE%\.cursor\rules\
# typically:
# C:\Users\you\.cursor\rules\Create the directory if it does not exist, then add individual rule files (often .mdc) the same way you would under a project .cursor/rules/ folder. Confirm the path in Cursor's docs for your version — UI labels say “User rules” / “global” while the disk path is under the home .cursor directory.
When AlwaysApply matters
A rule that lives in the right folder can still stay out of context. Cursor can treat rules as always attached, glob-scoped, or agent-requested. For global preferences you almost always want AlwaysApply (or the equivalent always-on setting for your version) so every chat loads them.
- AlwaysApply on — personal style that should never be optional (e.g. “prefer TypeScript strict patterns I always use”)
- Globs — only when the preference is file-type specific even globally
- Agent-requested — usually wrong for global user rules; you will think Cursor is not following rules when the rule never attached
If project rules also use AlwaysApply for everything, context gets noisy. Prefer AlwaysApply for a small set of global preferences; keep team/project rules specific and scoped.
What belongs global vs in the repo
Put in global user rules:
- Personal communication style with the agent
- Editor/agent habits that are not team policy
- Cross-repo preferences you refuse to re-type
Put in project .cursor/rules/ (or shared skills):
- API error shapes, auth patterns, testing conventions
- Anything enforced in PR review
- Anything a new teammate must inherit on day one
Team conventions in only ~/.cursor/rules is how you get “works on my machine” AI behavior.
Quick verification checklist
- Open the home-directory rules folder and confirm your file exists
- Confirm AlwaysApply (or equivalent) for rules that must always load
- Open a second unrelated project and ask the agent to recall a distinctive global preference
- If only one project obeys the rule, you likely wrote a project rule by mistake
When global rules are not enough
Global rules will never encode your team's PR history. For shared, evidence-backed conventions, keep project intelligence in the repo — Agent Skills and .codehabits/ are designed for that. Codehabits can extract those patterns from GitHub PRs so the team shares one source of truth; personal AlwaysApply rules stay in ~/.cursor/rules.
# team / project (shared)
npx @codehabits/cli enable
# personal (global) — still yours alone
# edit files under ~/.cursor/rules