How to prevent Cursor from repeating past mistakes?

Move each correction out of the chat into a rule that the next chat receives, confirm that the rule reached the chat where the mistake came back, and if it did and the mistake came back anyway, stop rewording the rule and put the check into something that runs: a hook, a linter or a test. Cursor's rules documentation gives the first step, "Start simple. Add rules only when you notice Agent making the same mistake repeatedly", and the loop after it: "When you see Agent make a mistake, update the rule." Two things decide whether that loop works: a repeated mistake has two causes with different fixes, and Cursor keeps lessons in several places that different parts of the product read.

TL;DR

• A correction in chat is not yet a lesson. It lives in the thread where you typed it. Put it in a rule; /create-rule in Agent writes one.
• Two failures, two fixes. If the rule never reached this chat (a folder scope, a rule type, a file pattern, a pointer file), fix where and how it is stored. If it was in context and the model chose otherwise, add a check that runs instead of stronger wording. Cursor staff have diagnosed both on the forum.
• Lessons live in separate places. Project rules do not apply to Bugbot, and Bugbot's learned rules come from pull request feedback and live in the dashboard. The pages read for this article do not describe those learned rules reaching Agent chat.
• Find out which one before rewording. Repeat the task in a new chat, and ask the agent to quote its rules word for word.

Mnemoverse (the author's company) makes a memory API for agents; it is not one of the places described below, and nothing below tests it.

Why does Cursor repeat a mistake you already corrected?

Because the correction was made in one conversation, and a new conversation does not carry it. Alden Harwood, on the Cursor forum on 26 September 2025: "If within a thread I correct it and tell it to 'use make test to test' then it often will continue and do so for the duration of the thread". It was the new threads that failed for him.

A long thread can lose a correction too. Cursor's prompting page: "When the window gets close to full, Cursor compresses older parts of the conversation into a summary to leave more room for new conversation." Dean Rie, Cursor staff, wrote on the forum on 31 August 2026 that summarization "can drop some instructions". Cursor's agent best practices list "The agent seems confused or keeps making the same mistakes" among the signs to start a new conversation.

A new chat clears the noise and the correction with it, so the correction has to leave the chat. The rules page: "Type /create-rule in Agent and describe what you want." And: "You can even tag @cursor on a GitHub issue or PR to have Agent update the rule for you."

Did the rule reach this chat, or did the model choose otherwise?

When a rule exists and the mistake still comes back, the rule failed in one of two ways, and Cursor's staff tell the two apart in their forum replies.

Mohit, Cursor staff, on 2 September 2026, to a user whose agent kept breaking his rules across chats: "Rules in infra/.cursor/rules/ only load when a chat is touching infra/ (even with alwaysApply: true), and pointer files only pass the path, not the rule itself." On another rule in the same reply: "Your GitLab-only rule is reaching the model, but some built-in guidance competes with it, so adding another 'no gh' rule won't reliably win." He added: "This isn't intended behavior, and we've let the team know." The first rule never reached the chat. The second reached it and lost.

Kevin Neilson, Cursor staff, on 9 July 2026, after reading a user's transcript: "From the transcript you pasted, the rules were actually in context. The agent still chose a bigger design over your constraints." Dean Rie, on 30 August 2026, to a user whose agent kept breaking the same Python rules: "So this is not a rules loading issue. The issue is how the rules get applied."

From outside the two look the same: the mistake comes back. The last row is the check that tells them apart.

For the first case, the FAQ of the rules page: "Check the rule type. For Apply Intelligently, ensure a description is defined. For Apply to Specific Files, ensure the file pattern matches referenced files." This case makes no noise. Ned C, in a dev.to comment of 23 February 2026: "the alwaysApply thing is brutal because nothing tells you it's not working. it just silently does nothing."

For the second case, Kevin Neilson, in the same reply of 9 July, on how rules work today: "they are strong guidance injected into the model prompt, not fail-closed runtime guards." Dean Rie, on 31 August: "So adding more rules often backfires." The Reddit user InteractionSmall6778, in a comment of 17 May 2026 on r/cursor: "The rules are still there, they just lose the attention war against 15 turns of error output."

An apology from the agent tells you neither case. Nikolaos Moraitis quoted his agent's reply on the forum on 3 August 2026: "That broke your rules. Won't do that again." Dean Rie wrote on 31 August 2026 that acknowledging and repairing does not improve compliance further in the same session, and called that "a result of the probabilistic nature of the model and the degradation in long runs".

What fixes a rule that was in context and still broken?

A check that runs outside the model's choice. javier marcon, on 30 August 2026: "So Agent clearly understands the rule once an external gate reports it." And: "The problem is that the same classes of violations are then introduced again in subsequent implementation work." Dean Rie's answer of the same day: "A hook on afterFileEdit can run your Ruff and module-size audit after every file edit and block the patch deterministically." In his words, "This is enforcement, not guidance".

Where the hook sits matters. Dean Rie, on 20 September: "afterFileEdit runs after the file is written." And: "What actually blocks an edit before the agent starts building dependent changes on top of it is preToolUse on the Write tool".

Cursor's documentation points the same way. The rules page, on copying a style guide into a rule: "Use a linter instead. Agent already knows common style conventions." The best practices post: "Use typed languages, configure linters, and write tests."

A hook has limits. Kevin Neilson, on 17 August 2026: "Hooks can hard-block specific files or commands." What stays a rule should be short: Kevin Neilson's advice of 9 July, "Keep must-obey constraints short, specific, and Always Apply (or in AGENTS.md)", and Dean Rie's of 20 September, "a short BAD or GOOD snippet in .mdc is picked up by the agent much better than abstract prose."

Where does Cursor keep a lesson, and what reads it?

The table lists nine places where a lesson can live in Cursor. Different hands write them and different parts of Cursor read them; the pages read for this article state for only some pairs whether one reads another.

Each row summarizes Cursor's documentation and staff replies on its forum, read on 4 and 5 November 2026; not a test.

Row sources: rules, rules help, prompting, Bugbot, Bugbot help, Projects, automations and the forum posts linked in the text.

Two cells matter most here. The Bugbot page: "Cursor project rules (*.mdc files in .cursor/rules/) do not apply to Bugbot runs." Both orders also begin with team rules, but the pages read keep them in two settings. The rules page says a Team Rule "is included in the model context for Agent (Chat) across all repositories and projects for that team", and the Bugbot page says "Team admins can create rules in Bugbot Automations that apply to all repositories in the team." Neither says that one list feeds the other. Until a page says so, a lesson that has to hold in the editor and in review is written for each: a project rule or a Team Rule for Agent, and .cursor/BUGBOT.md or a Bugbot team rule for review.

The community Memory Bank template, vanzan01/cursor-memory-bank, keeps lessons in files of its own: its reflect command "facilitates structured reflection on completed implementation, documenting lessons learned and process improvements." The plan command's own list of files it reads does not include the reflection or archive files. This covers the template's command files, not all its rule files.

Does Bugbot learn from past mistakes, and does Agent see what it learned?

Bugbot does, for its own reviews. Cursor's changelog of 8 April 2026: "Bugbot can now learn from feedback on pull requests and turn those signals into learned rules that improve future reviews." The signals, per the post on learned rules, are reactions and replies to Bugbot comments and "Comments from human reviewers, which flag issues that Bugbot missed." Candidate rules are promoted as signal accumulates and disabled when they stop being useful.

The Bugbot documentation: "Bugbot learns from a pull request when it's merged or closed." And: "You can also teach Bugbot new rules inline by commenting @cursor remember [fact] on any PR. Bugbot saves the fact as a learned rule and applies it to future reviews." The help page: "Learning is set per organization." Manual rules are the ones written by hand on Bugbot's repository rules page, not .cursor/BUGBOT.md, and the Bugbot documentation ties them to the Automatically Learn Rules switch: "Where that switch exists, manual rules apply only while learning is on, so turning learning off also stops manual rules from applying."

That @cursor remember saves a learned rule for Bugbot. The @cursor tag on the rules page has Agent update a rule file. They are different jobs.

One direction between the two is stated. Dean Rie, Cursor staff, on 16 July 2026: "Bugbot only reads context from .cursor/BUGBOT.md inside the repo itself, plus Team Rules and repository rules learned or manual from the dashboard." The other direction, learned rules reaching Agent chat, is not described on the pages read for this article. On those pages, a lesson Bugbot learned is a lesson for the review, and the review can run from Agent: "Use the /review-bugbot or /review skills to run Bugbot from your agent before you push the code." The section on that skill does not say which rules such a run includes, so a lesson Agent itself has to follow is still written where Agent reads.

Charles Gourdin named the cost in a feature request of 8 September 2026: "The issue is Bugbot's learned rules: they live only in the Cursor dashboard." Ofer Shapira tried turning repeated human review comments into project rules; two candidate rules passed his evidence bar, and he reported on the forum on 25 October 2026: "Result: only one rule passed testing on real code." That is one person's experiment.

What happened to Cursor Memories, and can an old lesson keep applying?

Colin, Cursor staff, on 26 October 2026: "in some cases Customize can leave out older account rules while the agent still loads them. This seems most likely on accounts that used the old Memories feature, which was retired in Cursor 2.1." So a mistake can also come back from an old lesson that the settings screen does not show. Colin wrote that he had "flagged this to the team" and gave a way to look: a new window with no folder open, then Customize, Rules. "If they show up there, you can edit or delete them from that window, and they'll stop being applied to your chats." Colin's check, on 14 October: "List every rule in your user rules section and quote each one word for word."

How do I check which failure I have?

1. Repeat the task in a new chat. Dean Rie's first question in a thread of 26 September 2025 was "Is this also happening in a new chat?" If the new chat gets it right, the long thread was the problem.
2. Ask the agent to quote the rule. Use Colin's prompt above for user rules; for a project rule, also check its type, description, file pattern and folder. A missing rule needs a new place, not new wording.
3. If the rule was there, look at the thread. Kevin Neilson's questions on 9 July 2026: "How full is the context window? Has it ever been compacted or summarized?"
4. If a short fresh chat with the rule present still breaks it, stop rewording. Add a preToolUse hook on writes, an afterFileEdit check, a linter or a test. A hook that crashes or times out lets the action through by default, per the hooks documentation.
5. Check reviews separately. After a bugbot run verbose=true comment on the pull request, the Bugbot documentation says, it "posts a table of every rule included in that run and flags any that were truncated or omitted."
6. Test a new rule on real code. Ofer Shapira, in his post of 25 October 2026: "Test on real code before treating a rule as law."

What this article does not claim

It tests no Cursor feature and gives no figure for how often Agent or Bugbot follows a rule. The staff lines are forum support replies about the cases in those threads, not documentation. The pages read do not describe Bugbot's learned rules reaching Agent chat; this article does not claim that they never do. No hook was run. The Memory Bank observation covers its command files only, and the check list is a proposal, not Cursor's procedure.

Sources and method. Every quotation except the Reddit comment was read on 4 November 2026 with two instruments, a browser-like request (on Cursor's documentation also on each page's Markdown version) and a reader service with its cache off; on 5 November 2026 the Bugbot, rules, Projects and automations pages and the forum posts added on that day were read again with both instruments, and a direct request found every quotation on the page it links to. Forum posts were also read through the forum's JSON and dev.to comments through the dev.to API; the Memory Bank files came from raw.githubusercontent.com. The Reddit comment rests on the thread's RSS feed alone, because the reader service does not serve Reddit. A made-up address on each host answered 404 as a control, and the reader service reported the same 404 everywhere except Reddit, where it refused the thread and the control alike. Staff status comes from the forum's own data. The text describes those pages as of those dates. Which files of the community Memory Bank template actually reach a Cursor session is covered in Cursor Memory Bank: What Actually Loads.

Edward Izgorodin · Mnemoverse · 2026-11-04