Cursor Rules Not Portable
Cursor rules are context, not a contract
A Cursor rule is an instruction source for Cursor's agent. In current Cursor projects, project rules live under .cursor/rules/*.mdc. They can include frontmatter, descriptions, and matching behavior such as file globs. Older projects may still have a .cursorrules file, which is a different shape and a weaker fit for newer project-rule workflows.
That storage location makes rules feel like part of the app. They sit in the repository, beside the code, so it is natural to assume another AI tool will see them and treat them as the project's operating manual. That assumption is where the portability problem starts.
Cursor rules are interpreted by Cursor. Cursor decides when to load them, which files they apply to, and how they are placed into the model's context. Another agent can read the text only if it is told to read the file or has its own convention for doing so. Even then, it does not inherit Cursor's rule selection behavior, frontmatter semantics, or UI-level treatment of the rule.
This is why a copied rule file can look successful while still failing in practice. The receiving agent may receive the words, but not the mechanism that made those words available at the right time inside Cursor.
Checklist: your Cursor rules are being treated as portable when they are not
.cursor/rules/*.mdcexists, but the new tool has no documented convention for loading.mdcfiles automatically.- The rule depends on frontmatter such as descriptions or globs, and the next agent only receives plain text.
- The instruction says what to prefer, but no test, lint rule, type check, or review step verifies the preference.
- The same rule mixes architecture, coding style, commands, and product behavior in one long prompt.
- The agent appears to follow the rule early in a session, then drifts after unrelated edits.
What carries over when you copy Cursor rules
The portable part of a Cursor rule is the human-readable intent. If a rule says the app uses server actions for mutations, avoids direct database calls from client components, or follows a specific folder convention, that instruction can still help another model. The idea is not locked to Cursor.
Plain-language guidance carries over best when it is short, concrete, and tied to visible code. A rule such as Use the existing Supabase client in src/lib/supabase.ts instead of creating a new client is more portable than Keep auth clean and consistent. The receiving agent can search for the file, compare the instruction to the code, and act on it.
Examples also travel well. If the rule includes a small approved pattern and a small rejected pattern, another agent can often infer the desired behavior even without Cursor's rule system. This is especially useful for React, Next.js, TypeScript, and Node.js apps where conventions show up as repeatable code structures. If your Cursor-built app is really a Next.js app or a React app underneath, portable guidance should describe the application rules in those terms, not only the editor rule format.
What also carries over is priority, but only if you say it plainly. A rule labeled as a hard constraint in prose has a better chance than a polite suggestion buried halfway through a long file. The agent still may ignore it, but at least the instruction is legible outside Cursor.
What breaks outside Cursor
The first thing that breaks is automatic loading. Cursor knows where Cursor project rules live. Claude Code may read a CLAUDE.md file at session start. Other agents may use their own instruction files, chat-level custom instructions, or no repository convention at all. ChatGPT may only know about a file if you paste it, upload it, or include it in the active context. The file path alone does not create a shared instruction layer across tools.
The second thing that breaks is scoping. Cursor project rules can be organized so specific rules apply to specific parts of the codebase. A rule aimed at API routes should not necessarily shape a CSS edit. When you paste all rules into another agent as one block, that scoped behavior collapses. The agent sees a pile of instructions and decides what seems relevant.
The third thing that breaks is metadata. Cursor's .mdc structure can include information that helps Cursor decide how a rule should behave. Another agent may treat that frontmatter as ordinary text, ignore it, or misunderstand it. The important instruction may still be present, but the execution model is gone.
The fourth thing that breaks is enforcement. AI rules are requests to a model, not runtime guarantees. Cursor can give those requests a better home inside its own workflow, but it still cannot make an architectural rule true if the codebase has no guardrail. Outside Cursor, that gap becomes more obvious. An agent may follow the instruction once, then contradict it later because nothing in the repo rejects the bad change.
That is the source of the familiar complaint that an AI coding agent quietly forgets an architectural rule from earlier work. The problem is not only memory. It is the absence of a durable, tool-independent check.
How to preserve intent when moving between agents
The practical move is to separate three things that are often mixed together in Cursor rules: project facts, agent behavior, and enforceable constraints. Project facts belong in a portable project spec. Agent behavior belongs in the instruction format for the tool you are using. Enforceable constraints belong in code, tests, linting, type checks, scripts, or review checklists.
For example, All authenticated data reads must go through src/lib/server/db.ts is a project fact and possibly an enforceable rule. It should live in a project spec that any agent can read. It can also be backed by code ownership, tests, or a search-based review. A Cursor rule can reference that fact, and a Claude instruction file can reference the same fact, but neither should be the only place it exists.
By contrast, Before editing, inspect related files and summarize the plan is agent behavior. It belongs in Cursor rules when using Cursor and in the receiving agent's own instruction system when using that agent. Copying the sentence may help, but the portable artifact is the habit, not the Cursor file.
A good transfer process rewrites rather than blindly converts. Start with the Cursor rules, extract the durable project decisions, then create a short instruction file for the next agent using its expected convention. Keep the app spec separate from the tool instructions so you can move again without rebuilding the whole knowledge base.
If your Cursor project is stuck because rules, prompts, and actual code have diverged, the immediate goal is not to perfect the rule format. The goal is to recover the real application contract and make the code follow it.
What a portable app spec should contain
A portable spec is not a prompt dump. It is a short technical source of truth that survives the editor you happen to use this week. It should be readable by a human, pasteable into an AI session, and specific enough to catch drift.
Use stable headings. Keep rules close to the code they govern. Do not include every preference you have ever given the model. If a rule cannot affect a code review, a test, or a concrete implementation decision, it probably does not belong in the portable spec.
For a small AI-built app, the spec usually needs these parts: the product boundary, the data model, the auth model, the routing model, the state management approach, integration rules, forbidden patterns, required commands, and known fragile areas. That is enough for another agent to understand the app without inheriting Cursor's mechanics.
Here is the key distinction. Cursor rules can tell Cursor how to behave while editing. A portable spec tells any competent builder or agent what the app is supposed to be. The first is tool context. The second is project knowledge.
When an app moves between tools, the spec should be the anchor. Cursor rules, CLAUDE.md, chat instructions, and agent-specific files can all point back to that anchor. If one tool ignores its local instruction file, the project still has a source of truth that can be reloaded, reviewed, and enforced.
Quick answers about Cursor rule portability
Can Claude or ChatGPT use my Cursor rules?
They can use the text if you put it into their context, but they do not automatically inherit Cursor's rule system. A .mdc file may contain useful instructions, yet another agent may not know to read it, may ignore the frontmatter, and may lose the scoping Cursor would apply. Treat the copied rule as source material. Rewrite it into the receiving tool's instruction format and keep the durable project facts in a separate spec.
Is converting .mdc to another rule file enough?
Conversion can save time, but it is not enough by itself. A converter can move words from one format to another. It cannot decide which instructions are project facts, which are editor habits, and which need real enforcement in the codebase. After conversion, review every rule for scope, priority, and testability. If the rule describes an invariant, back it with code or a review check rather than leaving it as a model suggestion.
Why does an agent follow a rule once and ignore it later?
AI agents operate inside limited and changing context. A rule can be present at the start of a session, then become less influential as the conversation grows, files change, or a more recent instruction competes with it. Some tools reload project instructions more predictably than others, but no prompt rule is the same as a compiler error. If the rule matters to the app, make it visible in the code and verify it with a repeatable check.
Should I keep Cursor rules in the repository?
Yes, if your team or workflow uses Cursor, project rules in the repository are useful. They give Cursor a consistent way to shape edits for that project. Just do not make them the only record of how the app works. Keep a tool-neutral project spec beside them, then let Cursor rules reference or summarize that spec for Cursor-specific behavior.
What should I do before handing a Cursor app to another builder?
Hand over the code, the current run commands, environment variable names, known broken flows, and a tool-neutral app spec. Include the Cursor rules as supporting material, not as the only documentation. The receiving builder should be able to understand the architecture without opening Cursor. If they cannot, the project knowledge is trapped in prompts rather than preserved in the app.
Cursor rules are useful when they stay in their lane. They help Cursor edit with better context, but they are not a universal memory layer for every AI coding tool. Once you treat them as one adapter around a separate project spec, moving between agents becomes less mysterious and less risky.
If your Cursor app only works when one agent remembers a private set of rules, the project needs a real technical source of truth.
AppStuck specializes in rescuing and completing Cursor projects, including rule cleanup, project-spec recovery, and codebase stabilization when AI context has drifted from the app.
Book a free 30-minute assessmentRelated posts
Need Help with Your AI Project?
If you're dealing with a stuck AI-generated project, we're here to help. Get your free consultation today.
Get Free Consultation