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!
Need this as well – I do most development inside devcontainers. Since ~/.cursor/plans/ for devcontainers is part of the container root, if you rebuild the container or destroy the container and make a fresh one, plan files are not persisted and are destroyed.
A backstop is that you can copy all the plans to the working directory and then have cursor inject them back into their correct ~/.cursor/plans/ later when you wish to rebuild the container but preserve your plans.
But if plans could be stored / sourced from the working directory itself, this whole concern dissolves away.
Hey, thanks for the detailed request. Good news, you can already do part of this today.
Plans have a Save to workspace action. It moves a plan from ~/.cursor/plans/ into .cursor/plans/ inside the workspace. After that, the plan lives in the project. It travels with the repo, can be committed to Git, shows up in the Plans panel, and stays isolated from plans in other projects. This covers the main motivations in your post: portability, version control, and project isolation.
What we don’t have yet is a default setting like cursor.plans.storage: "project" so plans are always created in the project automatically without manually using Save to workspace. I can’t share a timeline or make any promises.
On your naming request too, ISO 8601 prefixes instead of a hash like @richfromm suggested is a separate topic, and I’ve noted it.
Try Save to workspace on your current plans and let me know if it covers your use case in practice.
I’d like to be able to explicitly specify the file path where a Plan is saved (not just a default .cursor/plans directory), so I can keep documentation in the part of the repo where I organize my project docs. Ideally, Plan Mode would have an option like “Edit only this plan file at the path I provide,” allowing the agent to update that one document while leaving the rest of the repo untouched.
I had the same issue, so I asked Cursor to create a rule. I place this rule in every project, so when I open a project, Cursor will know about this. <project_dir>/.cursor/rules/plans-in-docs.mdc:
--- description: All project plans must live under docs/plan/ alwaysApply: true ---
# Plans location
Every plan, ADR-style design note, roadmap slice, or implementation plan for this repository belongs in [`docs/plan/`](docs/plan/).
- Create or update plans as Markdown files under `docs/plan/`. - Do **not** put plans in `.cursor/plans/`, repo root, `var/plan/`, or chat-only artifacts as the canonical copy. - If a plan was drafted elsewhere (e.g. Cursor plan UI), copy or move the durable version into `docs/plan/` and keep that path as source of truth. - Prefer clear filenames: `Topic_Name.md` or `topic-name.md` - Link new plans from the README docs table when they are long-lived architecture or roadmap docs.
Is this something that must be done manually every time someone has a new plan? I can’t say that’s the right solution here. It should be automatic. Have it default to the workspace/container/repo root folder ./.cursor/plans/
Nothing is lost. Zero thought required for the User. Context is contained to the project you are working on and not bloating/conflating the system when a User must switch contexts.
I have tried this and many other cursor rule incantations… they do not work deterministically. I for one am not a fan of the /rules impl. Nothing is for certain there. If they are indeed RULES they MUST be followed but with Cursor this is currently NOT the case.
: