Why did it edit a file in dist/ or .next/?

Those folders contain built copies of your source. They look like valid targets to a search. Add them to .cursorignore so they are not indexed, and only ever edit the source file.

Does having lots of tabs open really matter?

Yes. Open editors feed the model's context. Fewer, more relevant tabs produce more accurate targeting.

Is .cursorrules still the right file?

The current mechanism is project rules stored under .cursor/rules/ in your repo. Older single-file .cursorrules setups still appear in a lot of tutorials; prefer the rules directory for new projects.

Cursor keeps editing the wrong file

Cursor Last checked 2026-10-14

Cursor edits what it believes you meant, and it guesses from whatever is in its context: the open tab, the last file it touched, or a same-named file elsewhere in the repo. Fix it by naming the exact path with @, and by keeping only the relevant file open when you ask.

What you saw

You ask for a change to a component and the diff lands in a different file — often one with a similar name (Button.tsx vs button.tsx, index.ts in the wrong folder), or a copy under components/ui/ instead of components/.

Or it creates a brand new file that duplicates something that already exists, and your app keeps rendering the old one.

What it actually means

The agent does not see your repo the way you do. It sees a slice: your open editors, files you @-mentioned, files it found by searching, and whatever it read earlier in the conversation.

When several files plausibly match your description, it picks one. Monorepos, duplicated component libraries, src/ plus dist/, and generated folders all multiply the candidates.

Two common traps:

Stale context. The file it edited twenty minutes ago is still the most salient thing in the conversation, so vague follow-ups like "now add a loading state" land there.
Build output. It edits a file in dist/, build/ or .next/. The change is real but gets overwritten on the next build, which looks like the edit silently reverted.

The fix

Name the file explicitly with @ and the full path, not just the name. Do this even when the file is already open.

Confirm the target before you let it write. In Agent mode, say what you want checked first:

Before editing: list the exact file paths you are going to change and why. Do not write anything yet.

Close unrelated tabs. Open editors are context; a wall of them is noise.
Check the diff header, not just the diff. Reject the edit if the path is wrong rather than accepting it and asking for a second fix — the second fix usually lands in the wrong place too.
If it already wrote to the wrong file, revert that file first, then re-ask with the explicit path. Do not stack a correction on top of a bad edit.
Exclude generated folders from indexing so they stop competing for attention. Add a .cursorignore at the repo root:
```
dist/
build/
.next/
out/
coverage/
node_modules/
*.min.js
```

How to stop it happening again

Add a project rules file under .cursor/rules/ stating the folder layout and which directories are generated and must never be edited by hand. Rules get applied automatically, so you stop repeating yourself.

Kill the ambiguity at the source: if you have two files with the same name doing similar jobs, rename one. The agent is not the only thing confused by that.

Start a new chat for a new area of the codebase. Context carried from a different feature is the main cause of misplaced edits.

Work in small, reviewable diffs with a clean git tree, so a wrong-file edit shows up immediately in git status instead of three commits later.