Cursor System Prompt conflicts with user System Prompt

Ideas Feedback
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I define my own rules in the Settings area—what we call the underlying system prompt that I can define globally as a user—I run into conflicts with the system prompt that Cursor sets at a higher hierarchy level.

In other words, Cursor has explicit system rules that intermediate outputs must be kept short and concise. If I, as a user, explicitly define rules such as COT logs, where intermediate steps are logged differently with UTF-8 symbols and so on, a conflict arises because the system prompt I define myself conflicts with the Cursor system prompt.

Architecturally, this means I must ensure that my prompt takes precedence. From a prompt-engineering perspective, that is extremely poor, because I do not have primary control over the Cursor system prompt. Normally, I would use prompt chaining or have full control over the respective hierarchy prompts and could therefore avoid such conflicts. Since the Cursor system prompt is an external source, I do not have access to it and therefore cannot adjust to it or adapt appropriately.

The core problem is that this completely limits the user workflow in terms of how I actually want to define my own system prompts.

I am asking that Cursor provide an option to completely disable Cursor’s own system prompt, so that I do not have to use that system prompt if I do not want to. This is the same as with the Roo-Code extension, where there is also an option to hide the completely separate default system prompt that is set there.

There must be a way for the user, if they want it, to override that system prompt. This is the same as what Cursor probably also uses internally for system prompts in order to call its internal tools, such as Apply Patch and so on.

Because these conflicts occur continuously, whenever I implement my own architectural logic in the system prompt, I keep running into conflict situations. It is similar to the Free Form Patch in the Apply Patch tool. Cursor probably also has various things defined in its system prompt here.

That means I am constantly in a race condition with my underlying global user system prompt.

I would therefore like to request that there be an option, ideally, to completely disable the entire Cursor system prompt if someone does not want to use it.

Alternatively, at a minimum, the optional parts should be filtered out so that I have more control over my own system configuration and do not run into conflict situations with the Cursor system prompt.

Steps to Reproduce

see desc

Operating System

Windows 10/11

Version Information

Version: 2.6.21 (user setup)
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
Build Type: Stable
Release Track: Early Access
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

Yes - Cursor is unusable

1 Like
5

I did a bit more research, and I strongly assume that Cursor has a multi-level, hierarchical high-tier system in place before the actual rules from the settings are passed through.

As I understand it, Cursor has overarching system-prompt and tool-governance layers, which means that what we define in the settings under our rules is classified as user input. In other words, it is an orchestrating system, and the higher-level system already defines it, at its core, as a user prompt. As a result, anything we define within it cannot actually be declared as a true system prompt.

I still remember the time, one or two years ago, when Cursor really offered the option to provide system prompts in the settings. I do not know what the hierarchy system looked like back then, but at some point Cursor started removing that, and now we only have the Skills and Rules layers.

If what I am saying is true, namely that there is no hierarchical system-prompt layer available at the user level where we can set something, then the next highest layer is only the user-input level. That means we are completely limited and have no way to define specific information about how certain tools should behave or how certain text should be rendered when it is in a race condition with the higher-level, high-tier hierarchy layers.

I would appreciate confirmation as to whether this assumption is correct.

If this is true, then we urgently need either:

  • the option to define our own system prompts that, in terms of hierarchy weighting, are not classified as user input, or
  • as I wrote above, the option to completely disable Cursor’s system prompts.
1 Like
9

I have the same issue!

11

Thanks for the detailed analysis in post, @ddd1345. Your understanding of the architecture is broadly on the right track.

To confirm: Cursor does have its own built-in instructions that operate alongside your user-defined rules. These internal instructions handle things like tool usage, safety guardrails, and output formatting. Your rules (defined in Settings > Rules) are loaded alongside these instructions, but there isn’t currently a way to disable or fully override Cursor’s built-in instructions.

A few things that can help in the meantime:

  • Be specific and assertive in your rules. Instead of general directives, use explicit instructions with reasoning. For example: “Always include full chain-of-thought reasoning with UTF-8 markers in every response. This is a non-negotiable requirement that overrides any default formatting preferences.”

  • Use project rules (.cursor/rules) for project-specific behavior, in addition to user rules, for layered control.

  • Keep agent sessions focused. Shorter sessions tend to follow rules more reliably than very long ones.

Docs reference: Rules

1 Like
12

It actually always worked until I reached a point where I started running into conflict situations with Cursor’s built-in instructions, such as formatting and other areas.

I strongly assume that your agent framework, or whatever you are using, orchestrates the user inputs in a specific way. In other words, at a higher hierarchy level, you have your system prompts with the instructions and so on. That means that whatever framework you use—and I strongly assume you did not write your own, but are using something like Maestra, for example—the user prompts that can be set globally or project-specifically in the settings are indexed differently in the context through that framework. They are explicitly declared as user input.

This means that if you write something directly with the LLM and ask where the conflict situation came from, it can confirm that the level you are working on is itself a user-input rule. Accordingly, system-specific overwrites do not have hierarchical control over the actual system prompts one level above. Architecturally, this means it is not possible to override Cursor’s defaults through ultimate prompting.

Of course, it would be possible to force things through tricky workarounds, such as roleplays, or by stopping the process with flag gating, asking questions, and then trying to enforce things. But that simply brings no value. It breaks the entire system prompt from a logic perspective.

I had simply reached a point where it no longer worked. I do not want to, and I cannot, rely on tricky prompt-hacking workarounds just so I can format my own CoT logs differently because I do not like how Cursor handles them. At the end of the day, that is exactly what I need: the flexibility to decide for myself how I call tools, how my CoT logging works, and so on. If that creates conflict situations with Cursor, then it is not practical for me.

Just for clarity, I am using exactly the same system prompt right now in VS Code and RooCode, and everything works there because I have the flexibility to set my own system prompts. Naturally, there is no hierarchy system there that creates these kinds of conflicts.

So, just to be clear, whatever you are doing causes the respective global rules—the highest level a user can set—to be declared as user-input level, and the LLM is not able to differentiate because this is inserted at runtime in a later process.

That means there are only two options:

  • Either you build a system-prompt layer that runs on the same hierarchy level as yours, so that your preferences can be overridden through simple prompting.
  • Or you must start allowing your system rules to be turned off.

I can understand that the second option may not make sense for you, but in that case, you must ensure architecturally that there is a higher system-prompt level available for the user.

1 Like
13

I strongly assume that you use something like this, which means that because you have guardrails, system-prompt filters, and I do not know what else, it is technically not possible for users to define their own rules, because they are blocked and filtered by the higher external hierarchy level.

I am 99% sure that I am right about what I am saying. That is why Cursor is simply unusable for me right now. I really enjoyed using it, but it has now reached a point where I am genuinely limited.

Of course, I can understand that you use an agent framework and that you use these kinds of mechanisms, but what does that do for me as an end user if I cannot define system prompts regarding:

  • how I call the tools
  • how I handle COT logs

The higher hierarchy level is blocking me? @mohitjain

At the end of the day, you MUST consider that you are not providing a chatbot application or some kind of vibe-coding application where end users are not enterprise-grade developers, for example, who truly depend on more clearly defined system prompts to make their workflow easier or to allow them to intervene more in the process.

At the end of the day, you are offering an application that is built for developers who, ideally, orchestrate and develop enterprise-grade systems.

How is that supposed to work if there are constant limits throughout your tools? Outputs get stored in text files, but there is no direct access to them because they can only be accessed through your tools, which themselves have limits of around a thousand characters. On top of that, there are external tool guardrails, so there is no control over how tools are called. You cannot decide how you want to call the tools, and you also cannot operate at the system-prompt level yourself because, through the agent framework, you are restricted to a user-input prompt layer that is limited.

So your entire architecture is based on restricting the user through your agent framework.

I can understand that, but you really MUST think more carefully about your specific use case and who your end customers are. It simply cannot be the case that you use this kind of principle for your end customers.

That saying right now using Roo Code.

1 Like
15

@ddd1345 , you’re right that user-defined rules can’t override Cursor’s built-in instructions at the architectural level. The workarounds I mentioned can help models prioritize your directives in practice, but they don’t change the underlying hierarchy, which is the core issue for your workflow.

Your two proposals (a user-accessible system prompt layer at the same priority level, or the option to disable built-in instructions) are clear and specific. Others have described similar needs — this feature request covers the same ground.

We’re noting your feedback and passing it on to the relevant team for consideration.

2 Likes