Currently, Plans in Cursor are saved at the user level by default. I’d love an option to persist Plans within the project’s .cursor/ directory instead.
Plans turn out to be more useful than just a one-off thinking aid. In practice, they serve as:
A record of past reasoning — I often revisit Plans to recall why certain decisions were made or what approach I was considering.
Lightweight documentation — Plans naturally capture intent and context that formal docs often miss.
A hierarchical planning structure — A high-level Plan can be broken down into smaller Tasks or Sub-plans, making it a practical tool for managing complex work.
Saving Plans at the project level would unlock several benefits:
Portability — Plans travel with the project, so switching machines or onboarding a teammate doesn’t lose context.
Version control — Plans can be committed to Git, making the evolution of project thinking traceable.
Project isolation — Plans for different projects won’t mix together, keeping things clean and relevant.
Proposed behavior:
A setting (e.g. cursor.plans.storage: “project”) that, when enabled, reads and writes Plans to .cursor/plans/ (or a similar path) within the workspace root. The current user-level behavior would remain the default for backward compatibility.
I just asked Cursor if I could store these at the project level, and it pointed me to this feature request.
So yes, I’d like this too.
My other suggestion is some control over naming. The random hash at the end (I assume that’s what it is) is a fine option, but there are other things that would be useful. I’d like to see an ISO 8601-like prefix (maybe only minute level accuracy is needed), so the plans are sequentially ordered.
Fwiw, there are a lot of feature requests asking essentially the same thing (it’s about plan location on a per repo basis, although I added my sub-request for name control on some as well)
I’d like to link to them all, but cursor won’t let me put more than 2 links to a post. So these all start with https://forum.cursor.com
You know where your project is located but you may have no idea where Cursor stores its data.
If it’s under the worktree - it’s visible in the Cursor IDE, so it is accessible from the side panel and can be included into search. This is not possible if plans are stored somewhere else.
If multiple users work on the same project they would like to share the plans, but C:/Users restricts access to one local user only.
Customers may be extremely unhappy if their files are stored in some place other than approved shared folder.
Btw, Cursor itself considers current implementation as erroneous :
the consequences I can see:
Discoverability for tools — anything that scopes searches to the workspace (my own searches, rg, IDE-wide find) misses plans by default. I’ve now wasted tokens on it once; I’ll waste them again next time unless I remember to check ~/.cursor/plans/ explicitly. Memory is unreliable across sessions.
Discoverability for collaborators — a teammate cloning the repo gets the code but not the plan that explains why it’s shaped that way. Onboarding context is lost.
No git history for plans — they evolve in a directory that isn’t versioned. The “Changelog” section we just appended is the only record of design evolution, and it’s at the mercy of whatever is in your home dir on whatever machine you’re on.
Cross-machine drift — plans don’t follow you to a different workstation unless you sync ~/.cursor/ manually. Two machines, two divergent plan states.
Cross-customer commingling — your point. Plans for different clients sit in one directory keyed only by an opaque geometry_manager_refactor_a8525779.plan.md-style hash. NDA / IP-segregation problem if someone audits the directory.
Backup posture mismatch — engineering documents that should be backed up with the project end up in a profile dir whose backup policy is “whatever the OS does with %USERPROFILE%”.
This explanation was AI’s reply to me after I had to give it a path to the plan document which it created IN THE SAME SESSION a few prompts earlier. It couldn’t find it after switching from plan into agent mode and started writing new plan from the scratch when I told it to update some minor details.
Second that - same with transcripts! It makes moving from computers (use a fixed PC when working and a laptop when travelling) a total nightmare! Already complicated enough to manage .venv - why on earth should the 2 most important output from Cursor be held at a “local user” level? Makes the whole exercise a logistic nightmare and a very good opportunity for something to go REALLY wrong!
: