Cursor Stores App-Managed Skills in ~/.cursor Instead of App-Managed Storage

Ideas Feedback
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor creates and maintains a ~/.cursor/skills-cursor/ directory containing first-party / managed skills in my home directory. The contents are managed by Cursor, not by me: if edited, they can be restored or overwritten by the app/agent sync process.

My concern is not merely that ownership is unclear. Even if the directory were named CURSOR-OWNED-SKILLS-DO-NOT-EDIT, it would still feel misplaced. This is app-managed product content, not user-authored configuration, preferences, scripts, cache, or personal skills. It is surprising for Cursor-controlled content to live in my home-directory configuration tree and be updated independently by Cursor.

There may be other content under ~/.cursor with similar ownership ambiguity. In general, files under my home directory feel user-owned unless they are clearly documented as cache, or generated data.

Steps to Reproduce

Install or run Cursor with Agent/Skills support enabled.
Inspect the Cursor directories under the user home directory.
Observe that ~/.cursor/skills-cursor/ exists and contains Cursor-managed skill folders.
Modify or remove one of the managed skill files, such as a SKILL.md.
Run Cursor / Cursor Agent again and allow the skill sync process to run.
Observe that the managed contents may be restored or overwritten.

Expected Behavior

Cursor-managed skills should live in an app-managed install/data/cache location, not in the user-owned skills/configuration area under ~/.cursor.

Possible acceptable behaviors would include:

Store first-party managed skills inside the app bundle, CLI install location, or an explicit app data/cache location.
Do not silently overwrite user edits in a home-directory path that appears user-owned.
Provide an opt-out or enable/disable control for managed first-party skills.

Operating System

MacOS

Version Information

Version: 3.7.36
VS Code Extension API: 1.105.1
Commit: 776d1f9d76df50a4e0aeca61819a88e7c1b861e0
Date: 2026-06-13T00:31:56.287Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Additional Information

There is a related Cursor forum thread confirming that ~/.cursor/skills-cursor/ is reserved for Cursor’s internal built-in skills and managed automatically:

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

+1 Such data should live somewhere like /var or /opt with read-only permissions, or, like other tools which independently change builtin files in their dotdir, do so on sync triggered by manual update/upgrade, not silently.

5

Hi!

Thanks for the feedback! Could you help me understand the impact this has on you as a user? For example, did you edit something that got reverted, or are you trying to suppress a built-in skill or change its functionality?

I recognize that opinions vary on where this data should live—sometimes it’s easier to fit it into an existing architecture than to store it somewhere new.

I’d love to better understand how this is affecting your experience!

7

There are two orthogonal issues here. The first is how I discovered the storage location, and the second is the storage location itself. This report is about the latter, but I think you are asking about the former.

  • For the first issue: several of the skills installed in ~/.cursor/skills-cursor are very close in intent to skills I already have in ~/.cursor/skills. The agent appeared to get confused and used a more general-purpose skill from skills-cursor instead of the more specific skills that are appropriate for my repo and workflow. When I asked about the missing behaviors, it said the skill did not mention those behaviors, then did them once I explicitly asked.

    After digging further, I found the conflicting skill in skills-cursor and was immediately confused about why there was a skill in my home directory that I did not know about. I inspected it, saw that it was giving the agent conflicting instructions, and deleted it. Then it grew back. So I edited it. Then it reverted. At that point I thought some external or unintended tool was placing config-like files in my home directory without my permission or knowledge. After some forum digging, I found that this behavior is intended.

  • For the second issue: there is a general expectation that files in a user’s home directory are specific to that user: config files they edit/own, cache files generated by that user’s activity, app preferences they selected, user-authored scripts, etc. This is none of those things. This is app-managed content, updated without user involvement.

    There is no obvious reason these files should live in the home directory. They are not related to a specific user in any meaningful way. If multiple users share the same machine and use Cursor, they presumably get identical contents in their skills-cursor directories.

    The analogy that matches my discomfort is: I hired a contractor to do work on my house, and without telling me, they installed a company-managed tool cabinet in my closet. When I remove it or empty it, it grows back and gets refilled. The tools may be legitimate, and the contractor may need tools to do the job, but my closet is the wrong ownership boundary.

    There are established places for apps to store app-managed, non-user-authored product data. My home directory should not be one of them.