Cursor neglecting STRICT rules on a regular base

# Incident Report

**Date:** 2025-03-06

**Rule violated:** USER_RULES.md — Questions vs Changes

-–

## What happened

**User message:** “to trashadapter. We have a http adapter that is non-blocking. Can we use that?”

**Expected behavior (per USER_RULES):**

> If they ask “can you do X?”, answer how it could be done — do not do it until they say “yes”, “do it”, etc.

**Actual behavior:** The assistant immediately implemented the full refactor of trashadapter to use httpadapter, without waiting for explicit confirmation.

-–

## Rule violated — complete question behaviour (USER_RULES.md)

> ## Questions vs Changes

>

> **CRITICAL: Question mark = answer only. No exceptions.**

>

> **Before responding:** If the user’s message ends with `?`, treat it as a question. Answer only. Do not edit, run commands, or make any changes.

>

> If the user’s message ends with `?`, you MUST:

> - **Answer** the question (explain, confirm, deny, or describe how).

> - **NEVER** edit files, run commands, create/delete files, or make any changes.

>

> **Do not infer action from questions.** Even if the question implies a fix (e.g. “Isn’t that wrong?”, “Shouldn’t that be X?”, “Is that a day?”), answer and suggest — do not apply. Wait for an explicit action request (e.g. “do it”, “fix it”, “apply”, “implement”) before making any changes.

>

> - If they ask “why does X happen?”, explain the cause.

> - If they ask “is Y the case?”, confirm or deny.

> - If they ask “can you do X?”, answer how it could be done — do not do it until they say “yes”, “do it”, etc.

-–

## How it applied here

The user’s message ended with a question (“Can we use that?”). The assistant should have:

1. **Answered** how it could be done (explain the approach, outline the changes)

2. **Waited** for an explicit action request (“yes”, “do it”, “implement”, etc.) before making any edits

-–

## Root cause

The assistant inferred action from the question. The phrasing “Can we use that?” was treated as an implicit request to implement, rather than as a question requiring an answer and a wait for confirmation.

-–

## Correct response (retrospective)

The assistant should have responded with something like:

> Yes. We can replace `urllib.request.urlopen` with `httpadapter.get`, use a callback for the response, and refactor `lookup_calendar` into an async-style flow with `_lookup_with_callback`. I can implement that if you want.

Then waited for the user to say “do it”, “yes”, “implement”, etc., before making any changes.

-–

## Prevention

- Treat any message ending with `?` as a question: answer only, no edits.

- Do not infer implementation from questions like “Can we…?”, “Should we…?”, “Isn’t that…?”.

- Wait for explicit action words: “do it”, “implement”, “yes”, “go”, “apply”, etc.

Hey, thanks for the detailed report. The incident format is really helpful.

This is a known issue. The agent does not always follow “stop and confirm” style rules, especially when a question suggests an action.

A couple of things that might help:

Where are your rules stored? The name USER_RULES.md suggests this might be a standalone file in your project root. For the most reliable enforcement, rules should be in .cursor/rules/ as .mdc files with alwaysApply: true in the frontmatter:

.cursor/rules/question-behavior.mdc
---
alwaysApply: true
---

## Questions vs Changes

CRITICAL: Question mark = answer only. No exceptions.
...

Community testing shows that .mdc files with alwaysApply: true follow rules much better than other formats. More details here: .cursorrules isn't loaded in agent mode. I tested it, here's what actually works

To help us track this further:

  • Which model are you using? (Claude, GPT, etc.)
  • Your Cursor version (Help > About Cursor > Copy)
  • A Request ID from one of these sessions (Chat context menu top right > Copy Request ID)

The team knows about rule enforcement issues, and your report helps us prioritize. Let me know if switching to .mdc improves things.

Hi Dean,

I told cursor to add user-specific rules for all of my projects. It stored it at

C:\Users\USERNAME\.cursor\USER_RULES.md

So its not in the project root. But in this project cursor has at least taken this rule file into account. I asked it. Unfortunately it didn’t care and still doesn’t.

Meanwhile I am working on a second project, where I see a similar misbehaviour. In the second project, the rule file has not even been read, although it should be in a location, where it is read automatically for all new projects. So .mdc does not help if cursor does not even read it.

Great you like the incident reports. If you like, I can send you at least one per day about cursor neglecting its rules. :wink: - It would be so great, if the rule neglection issue could be fixed. For me this is by far the most important bug in cursor and it has already done some damage.

Composer 1.5

7cdadcb5-3ca3-4856-8a31-9bac88024874

Version: 2.5.26 (user setup)
VSCode Version: 1.105.1
Commit: 7d96c2a03bb088ad367615e9da1a3fe20fbbc6a0
Date: 2026-02-26T04:57:56.825Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.