When starting a new conversation or using Composer, Cursor automatically scans and loads an excessive number of “Skills” from the ~/.claude/skills/ directory. Even though it only reads the frontmatter rather than the full file content, the sheer volume of loaded skills consumes a significant amount of the initial context window (tokens).
Specifically, Cursor is recursively scanning hidden directories within the skills folder, loading skills meant for other Agent CLIs (like openclaw) that are not relevant to the current session.
Duplicated SKILLs will also be loaded. E.g. when you install GStack, same SKILLs from ~/.agent/skills and ~/.claude/skills will be loaded
Steps to Reproduce
Have a directory structure in ~/.claude/skills/ that contains many subdirectories or hidden folders (e.g., .hermes/ or .opencode/).
Start a new chat or Composer session in Cursor.
Observe the initial token count or check the context being sent to the model.
Notice that skills from paths like ~/.claude/skills/gstack/.hermes/skills/…/SKILL.md are being included.
Expected Behavior
Ignore hidden directories (starting with .) within the skills folder.
Hey, thanks for the detailed report and the screenshot. Confirmed: the recursive skills scanner doesn’t filter hidden directories inside ~/.claude/skills/, so anything in .hermes/, .opencode/, .gstack/, and similar subfolders from other agent CLIs gets pulled into context. I’ve reported this internally.
On dedup: normalization works for ~/.claude/skills vs ~/.cursor/skills, but GStack stores skills in ~/.agent/skills (no s at the end), and we only detect ~/.agents/skills. That’s why duplicates don’t collapse in your case. Flagged this too.
No fix yet. Workaround: turn off Include third-party Plugins, Skills, and other configs in Settings → Rules, Skills, Subagents. This will stop loading from the .claude/, .codex/, .agents/ roots entirely, including skills you might want, so if you need them you can temporarily copy specific folders into ~/.cursor/skills/.
thanks. is there a way to set this for cursor-agent as well? your response seems to be for the cursor gui and im not sure if that translates over to what cursor-agent pulls in.
I have a similar issue but more focused on ~/.cursor/skills-cursor/.
For me it’s not really about context size — it’s that agents spread their focus onto irrelevant built-ins like create-skill or create-rule even when the task has nothing to do with that. These are clearly commands, not auto-invocable workflows. I manually moved them to ~/.cursor/commands/ and that did the trick — but every Cursor update re-downloads anything missing from skills-cursor/, so the fix doesn’t survive. I’ve ended up writing a small script that purges the folder and marks it immutable with chflags uchg after each update.
What I’d love is a first-class option to disable built-ins — skills, subagents, commands, and (if you’re generous) tools. I’ve been using Cursor as my main tool for a while and have a clear sense of how I want the agents’ environment shaped; let me shape it.
@jubi - right now the toggle Include third-party Plugins, Skills, and other configs is an IDE-only setting. In ~/.cursor/cli-config.json docs Configuration | Cursor Docs there is no equivalent flag documented, it only has editor and permissions. Also, the cursor-agent CLI handles skills differently in general. There are a few parity gap reports, for example this one Cursor-agent CLI does not register skills from plugins (IDE does — parity gap) and this one Cursor CLI does not load ./claude/skills, so skills behavior in CLI vs IDE is not symmetric right now. I marked it internally as a gap. When we fix hidden-dirs filtering, we’ll also take a look at the CLI side.
@Demianight - this looks similar by symptoms, but it’s a different case overall. Built-in skills from ~/.cursor/skills-cursor/ are currently seeded automatically and re-populated on update, and that’s by design at this stage. What you want is a first-class option to disable built-ins skills/subagents/commands. That’s a reasonable feature request, but it’s broader than the hidden directories bug from the original thread. Can you open a separate thread for it? That’ll make it easier to track and prioritize separately, without mixing it with the fix for scanning .claude/skills. The chflags uchg workaround is valid for now, even if it’s a bit fragile.