Debugging Cursor's wrong suggestions: a checklist for when the model is being weird
Published 2026-01-31 by Owner
Cursor’s suggestions are usually good. When they’re not, the cause is rarely “the AI is broken.” It’s usually one of six predictable issues. Here’s the checklist I run through.
1. Stale codebase index
Cursor’s chat panel uses an indexed view of your codebase. If you’ve recently:
- Pulled major changes
- Renamed a bunch of files
- Switched branches
…the index may be stale. Suggestions reference old patterns or missing files.
Fix: Settings → Codebase → Re-index. Wait for completion. Try again.
2. Wrong files in context
Cursor’s chat decides which files to load based on your message. Sometimes it picks wrong. The model produces suggestions based on irrelevant context.
Fix: Pin the correct files explicitly with @-mentions. Force Cursor’s hand. If you’re working in src/auth/, pin src/auth/middleware.ts and src/auth/types.ts before asking your question.
3. .cursorrules not loading
A common issue: you wrote .cursorrules but the model isn’t following it. Causes:
- File is at the wrong location (must be repo root)
- File has wrong name (
.cursorrulesexact, no extension) - File is gitignored and you’re in a fresh worktree
- New nested rules format isn’t being recognized
Fix: Check the file location and name. Verify by asking Cursor “what conventions do you follow for this project?” and seeing if your rules show up.
4. Model selection mismatch
Different models have different strengths. If you’re using GPT-4o for a task that needs Claude’s instruction-following, suggestions will drift from your rules.
Fix: For complex tasks, switch to Claude 3.5 Sonnet or Claude 3.7 Sonnet. The model selector is in the chat panel.
5. Context overflow
If your chat conversation is long, the system prompt and pinned files compete for context space. Cursor truncates somewhere; you don’t see the cut.
Fix: Start a new chat for unrelated tasks. Don’t keep one chat going for hours across many topics.
6. The model is just having an off moment
Sometimes models produce bad output for no clear reason. Maybe a token sampled wrong; maybe attention drifted; maybe the prompt hit a weird intersection of training data.
Fix: Try asking again with slightly different framing. About 30% of the time, a re-ask produces meaningfully better output.
A specific debugging session
A real example. I asked Cursor to add a function. The output used Lodash, which isn’t in my project. The .cursorrules file says “no Lodash; use ES built-ins.” Why did it ignore the rule?
I went through the checklist:
- Stale index? Re-indexed. No change.
- Wrong files? Pinned the relevant files. No change.
- .cursorrules loading? Asked Cursor to confirm conventions. Cursor’s answer didn’t mention the no-Lodash rule.
- Model selection? Was using GPT-4o. Switched to Claude. Same issue.
Issue isolated: the rules file wasn’t loading. I checked the file path. It was .cursorrules.txt, not .cursorrules. The IDE had auto-added the extension when I created the file.
Fixed by removing the extension. Cursor immediately picked up the rules. The Lodash suggestions stopped.
This was a 15-minute debugging session. Without the checklist, I’d have spent longer trying random things.
Prevention patterns
A few habits that prevent these issues:
Re-index after big changes. Habit of running re-index after a major branch switch or refactor.
Pin files at the start of important chats. Don’t trust automatic context loading for serious work.
Verify rules at session start. Quick “what conventions do you follow?” question to confirm Cursor sees your rules.
Start fresh chats often. When a chat has been going for 30+ minutes, start a new one. Stale context is real.
Switch models for hard tasks. Don’t use the cheap default for tasks that need stronger reasoning.
These are small habits. They prevent most of the “Cursor is being weird” sessions before they start.
When the issue is real
Sometimes the issue isn’t operational — it’s that Cursor genuinely doesn’t know your codebase well. For very large repos, very niche frameworks, or very recent libraries, Cursor’s training has gaps.
For these cases, the answer isn’t a checklist; it’s adjusted expectations. Cursor will produce more friction; you’ll do more correction. The productivity gain on these is smaller than on mainstream stacks.
Knowing which is which matters. Operational issues are fixable in minutes. Capability gaps are not — they’re a property of the tool and the codebase combination, and you adjust your workflow rather than chase a fix.
What I’d want from Cursor
A “diagnostic mode” that surfaces what’s happening would help:
- Which files are in context right now
- Which rules are active
- Which model is responding
- Confidence level of the response (if estimable)
Right now, all of this is opaque. The user has to infer from output quality. A debug panel that shows the actual state would make troubleshooting much faster.
Until that ships, the checklist above is the practical answer. Six steps, runs through in 5 minutes, fixes 90% of issues.