AI engineering · Problem-solution
Cursor loses context on long projects. Here is the operational fix.
Cursor is great until your codebase is too big to fit in its head.
On a small repo, Cursor is magic. On a real codebase — fifty files touched in a sprint, three modules with conflicting conventions, a deprecation you flagged Tuesday — it drifts. The pain is not the model. It is the absence of a memory layer scoped to the repo and the file you are actually editing.
→ Read the deep technical guide (Claude Code, same concepts)What Cursor context loss actually is on a large codebase
Cursor's working memory is its open tabs and the slice of the repo it has indexed. The longer the project runs, the more the gap shows: a function you discussed in module A gets re-questioned when you open module B. A naming convention you set on Monday gets violated on Friday. The agent is not malicious — it does not have the convention loaded in its current context.
Two specific failure modes dominate on large codebases. First, cross-module amnesia: a decision taken in one part of the repo does not propagate to another. Second, retroactive drift: a convention enforced consistently for two weeks is forgotten the moment a new file gets opened from a deeper folder.
Why "just give it more files" does not fix it
More files in context, more noise in retrieval
Cursor can index a large repo, but indexing is not the same as recall. A semantic similarity match against a 5,000-file corpus surfaces plausible neighbours, not the specific convention you set last Tuesday. The bigger the codebase, the worse the signal-to-noise on raw retrieval.
The IDE session is bounded, the repo is not
Even with perfect indexing, the IDE session ends. A close-and-reopen wipes the conversational state. What survives is what got committed; what got committed is the code, not the reasoning behind it. The agent re-asks the same questions because the answers were never stored.
Closing tabs is the silent reset
Cursor power users keep tens of tabs open to preserve in-session context — until a window crash, a restart, or a refactor sweeps them away. The tabs were the memory; nothing survives them. What feels like "Cursor is so much better today than yesterday" is often just yesterday's working state quietly disappearing. Operational memory survives a tab wipe. The patterns scoped to a file glob load themselves the next time you open a file under that path.
The hidden cost on long Cursor projects
On a long project, the visible cost is the time spent re-anchoring the agent on conventions every time you switch modules. Annoying, but trackable.
The expensive cost is the convention drift you only notice in review: a PR conforms to the rules of the file it edits but violates a rule set three weeks ago in a sibling module. The diff is plausible, the tests are green, and the inconsistency only surfaces when a third engineer reads both files side-by-side.
On a sprint timeline, the cost compounds. Module-by-module review catches the obvious drifts; the subtle ones — a naming convention applied 80% of the time, a convention violated only in one corner — slip through and become tech debt. Six months later that tech debt reads as "the agent's code," and the team's instinct is to use the agent less. That is the trust erosion the catalogue prevents.
Real GNETICS scenario
Problem. We used Cursor to ship a multi-module refactor across an established codebase. The convention "all timeouts handled at the route boundary, never inside the retry loop" had been agreed two weeks earlier and applied to half the modules.
What failed. Cursor edited the second half of the modules without re-reading the first half. The new code looked clean in isolation. It re-introduced retry-loop timeout handling in three files because that convention had never made it into anything Cursor could retrieve from inside the new module's context.
What changed. We attached an executable pattern to the convention — execution_stage "before_edit", tool_name "edit_file", scoped by file path glob. Cursor now retrieves it when editing any file under the relevant tree, not when the convention happens to be in the open tab.
Measured operational effect. Convention drift in PR review dropped to a fraction of what it was. The agent stopped re-asking "should I handle the timeout here" because the pattern returns the answer the moment the file matches.
The fix: operational memory scoped to the repo and file
Cursor exposes external tools via MCP, the same protocol Claude Code uses. The fix is not Cursor-specific magic — it is a typed memory layer queried with the right scope: the active repo, the active file, the current stage of execution.
An executable pattern attached to a convention or a repo-level rule looks like this:
{
"execution_stage": "before_edit",
"tool_name": "edit_file",
"error_signature": "TimeoutError waiting for FTS5 rebuild",
"expected_behavior": "Warm the FTS index in a readiness probe before \
serving traffic; never block first request on rebuild.",
"stop_condition": "Tests not green OR readiness probe missing.",
"doc_reference": "/blog/claude-code-context-loss#stop-conditions",
"quick_fix": "Trigger a no-op INSERT/DELETE in a startup hook to warm \
the FTS index before serving traffic.",
"root_fix": "Replace FTS5 rebuild-on-attach with explicit \
SELECT * FROM patterns_fts LIMIT 1 in the readiness probe.",
"tags": ["fts5", "sqlite", "warmup", "readiness-probe"],
"status": "resolved"
}The retrieval is scoped before similarity ranking. Patterns tagged for module A do not surface when editing module B. The agent receives a small, relevant, file-aware set of patterns — not a 14,000-character preamble it can no longer fit in attention.
The retrieval is filtered before similarity ranking, which matters more on Cursor than it does on a small chat agent. With a 5,000-file monorepo, semantic similarity alone surfaces too many plausible neighbours. Filtering by repo, by file glob, by execution stage cuts the set down to the patterns that actually apply to the file currently open. The agent receives a small, sharp set of operationally relevant rules — not a flood of "this looks vaguely related" matches.
Wiring it to Cursor via MCP
Cursor's MCP integration treats external memory as a first-class tool. The setup is the same shape as for Claude Code, adapted to repo scope.
1. Define repo-scoped scopes on contribute
When the agent contributes a pattern, store the repo, the file glob, and the execution stage. Retrieval becomes a filtered query, not just a vector neighbour search.
2. Expose memory.search and memory.contribute through MCP
Declare a memory server in the project's MCP config. Cursor surfaces both tools in its agent loop.
3. Set the convention in the system prompt
Instruct the agent: before editing any file, call memory.search with the file path and the task. Patterns scoped to that path surface first.
Frequently asked questions
Why does Cursor lose context on long projects?
Cursor's session memory is bounded by its open tabs and the slice of the repo currently indexed. On a long project the relevant context expands faster than the window. The agent re-asks the same questions because the answers were never persisted in a form it can retrieve.
Can MCP fix Cursor context drift?
MCP is the wiring — it lets you expose an external memory tool to Cursor's agent loop. The fix is the memory layer behind MCP, not MCP itself. A memory layer with typed, executable, file-scoped patterns is what stops the drift.
How is this different from Cursor's built-in repo indexing?
Indexing surfaces semantically similar code. It does not surface the conventions and decisions you made out-of-band. Operational memory stores typed records of those decisions, scoped to where they apply, and returns them as actionable patterns instead of as code neighbours.
Will turning on "include codebase" mode fix it?
It delays the failure. Loading more codebase into the prompt costs tokens, degrades attention on long contexts, and still does not carry over to the next session. External memory queried on demand scales; bigger context windows do not.
Does this work for monorepos?
Yes — that is exactly the case where scope-aware retrieval pays off. Patterns get tagged with the relevant package or path glob. Retrieval becomes a filtered query, so a pattern from package A never surfaces when editing package B.
Will this slow down Cursor's response time?
A search call adds one round-trip to the agent's planning step — typically tens of milliseconds against a local memory backend, lower than the model's own latency. The payoff is fewer wasted turns: the agent does not need to ask you to clarify the convention when the convention surfaces in retrieval.
If your team spends more time rebuilding context than shipping, the bottleneck may not be the model — it may be the absence of operational memory.
GNETICS OPS was built around that single assumption.