Cursor agent does not even know how its own rule system works?

[jrista]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Whenever I instruct the agent to create a new cursor rule, the agent and model never seem to know how rules in cursor work. I have encountered countless different ways the agent INCORRECTLY creates rules, and not once, not ever, have they ever actually created a rule file CORRECTLY, the first try, in the right location.

First, almost universally, it creates a .md file, not a .mdc file. Always, a .md file. Even when I’ve instructed it to create a .mdc file, the agent will often create a .md file instead. When it does actually create a .mdc file, it will create one that initially had the header block. However, 90% of the time the header block is actually a footer block. Then the agent will notice that, and delete the footer block. And not add a header block. When I instruct the agent to create rules that are “Apply Always” or “Apply Intelligently”, it will always leave them as “Apply Manually”. It WILL NOT create an always or intelligently applied rule. Usually, though, even if it does initially add the header block, or somehow generate one…pretty much inevitably, as a final edit…it will then go back and delete it…

Second, the agent simply does not know where to put the darn things. I have not once, in my 6+ months of using Cursor now, observed the agent creating a rule in the right location, which since I’ve been using it has been .cursor/rules/*.mdc as separate fils. Instead, I’ve had rules generated in the following locations:

<workspace-root>/*.md
<workspace-root>/.cursorrules/*.md
<workspace-root>/.cursor-rules/*.md
<workspace-root>/cursor-rules/*.md
<workspace-root>/.cursorrules/rules/*.md
<workspace-root>/.rules/*.md
<workspace-root>/rules/*.md
<workspace-root>/<project-root>/.cursorrules/*.md
<workspace-root>/<project-root>/.cursor-rules/*.md
<workspace-root>/<project-root>/.cursor/cursorrules.md

And there are many others. Just. Never, the actual, correct, required, place… I have even created rules, about creating rules! Its becoming ludicrous at this point. Why is it, that Cursor’s own agent, is completely oblivious to how its own rules system works?

Steps to Reproduce

• Instruct bot to create a rule.
• Observe odd behavior as model tries to figure out how…
• Observe odd creations as model generates something incorrect…
• Weep at the idiocy of it all…

Expected Behavior

• Rules are created in correct locations
• Rules are created with correct format
• Rules include required header block
• Header block conforms to instructions provided by user

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.53
VSCode Version: 1.99.3
Commit: ab6b80c19b51fe71d58e69d8ed3802be587b3410
Date: 2025-10-20T19:15:58.572Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the report. Since MD is the de facto standard for rules and documentation, the model generates content in that format. As for whether Cursor knows about the rules system, Cursor has a built-in /generate cursor rules command. When you use it, the agent will create the rules in the correct format and place them in the right location: cursor/rules.

Let me know if this works.

[jrista]

I wonder if my use of a workspace is causing some of the problems. I have a bunch of independent git repositories, in a single directory. We talked about using a monorepo at one point, however, given Cursor’s lack of uspport for git workspaces, we decided to keep independent repos for most of our projects. This allows us to have separate agent tabs working on things in different repos at the same time.

However, I wonder if somehow, this has confused Cursor? The structure I currently have is:

/workspace-root
  /.cursor
    /commands
    /rules
  /project-a
    /.cursor
      /commands
      /rules
    /...
  /project-b
    /.cursor
      /commands
      /rules
    /...
  /...more projects...

I figured the workspace root would be easy, but, it doesn’t seem to understand that either. Originally, we were opening each individual repo in a separate cursor instance. That rapidly caused memory issues, and then when we needed context from other projects it wasn’t possible, so we moved to this structure.

Even before, when we opened individual projects, the agent didn’t seem to understand how to deal with rules. That said, we were never using the /generate cursor rules command, we didn’t know about it. I’ll give it a try, but, I do wonder, where it will be putting the rules. We have project specific rules and workspace global rules. I thought the rules system was hierarchical? Is that true?

[deanrie]

Cursor supports nested rules in multi‑root workspaces:

Workspace root: .cursor/rules applies globally across all projects
Project level: .cursor/rules inside a specific project applies when working in that project
Nested rules automatically supplement parent rules

Your structure looks correct. The /generate cursor rules command should place rules into .cursor/rules based on the current context (current project or workspace root).

Rules | Cursor Docs

[Cheez_One]

@deanrie

/generate cursor rules

1.9.0-pre.2.patch.0 (user setup)
1.99.3
2c68a0136322d6944de6f75556127ae683790860
2025-10-21T08:31:09.849Z

Not working…

/ only show Summarize and Agent Review

[jrista]

@deanrie Same experience for me on 1.7, I am not sure that cursor is properly handling rules in nested scopes. A lot of my rules don’t seem to get applied, even if they are marked as Always Apply. I usually have to manually reference them in the prompts if I want them to apply.

Another issue I have noticed, starting as far back as 1.4 I think, is that when I ask the agent to check for rules that apply to the current context, the agent will invoke a tool to find rules, and it 100% always, without fail, only ever returns no rules found.

This is similar to the list mcp tools command as well, it does the same thing. I DO have MCPs configured, but if the agent tries to list mcps it always returns an empty list.

This is part of the systemic breakage that I have experienced with Cursor. Even after a complete uninstall and deep scrub of ALL cursor content on my computer, and a fresh install, my issues have persisted.

I am starting to suspect that there may be some account-level factor involved here, given the persistence and cross-version nature of my issues, which seem to be very extensive now. It mostly revolves around the agent and agent @ or / commands, most if not all of them, and even general behavior around attaching context items. There seem to be some severe issues there. I know I am not the only one who experiences these issues, but I also know that not everyone experiences them.

[jrista]

As far as I can tell, the /generate cursor rules command only tries to generate them in my workspace root. Even if I specify a project it doesn’t seem to generate them anywhere else. Additionally, I have been able to confirm that custom commands ONLY work if they are placed in my workspace root .cursor/commands/ directory. They do not work when placed anywhere else…

[Cheez_One]

He seems to have abandoned it. I observed that the rules no longer allow artificial intelligence to retrieve the rules.

[jrista]

Aye, I have observed the same problem. This has actually been an issue for some time now, as my average rules applied to each prompt, dropped from 16-18 down to 7-9.