Why does Cursor forget my file structure?

Cursor forgets your file structure because its codebase indexing is approximate, not authoritative: the model sees retrieved snippets, not the full directory tree, and Rules files do not fully encode folder conventions. Once a session grows, structural guidance loses weight against the recent code in the prompt, so Cursor falls back to generic React/Node defaults. The fix is to expose your real structure as queryable memory.

Cursor indexes your codebase and uses retrieval to feed relevant chunks into the prompt. Three realities of that pipeline explain the structure drift.

1. The model sees snippets, not a tree. Codebase indexing returns relevant file contents, not a full directory map. The model can usually guess your structure from what it has seen, but for a folder it has not touched in this session, it falls back to defaults.

2. Rules describe behavior, not topology. Project Rules (.cursor/rules/*.mdc) are good at "use Zustand for global state" and bad at "components live in src/features/<feature>/components/, hooks in the same folder, tests with .test.tsx suffix." Encoding topology in prose is brittle and competes with code for prompt budget.

3. Context evicts under load. Once a session loads many files, the model's effective working context drops, and earlier structural cues lose weight. Cursor users routinely report file-placement drift on larger refactors for this reason.

The result: Cursor places files correctly when the surrounding code makes the convention obvious, and drifts to generic defaults when it does not.

Every misplaced file costs you a move-and-fix cycle, and the cost compounds across a codebase:

• Files land in the wrong folder. A new hook gets dropped in src/hooks/ instead of next to its component, breaking your colocation convention.
• Imports point at fictional paths. Cursor invents @/lib/dateUtils because the alias and folder name sound right, even though your actual util lives at @/utils/date/format.ts.
• Test files end up orphaned. You keep .test.tsx next to source; Cursor creates __tests__/ because that is the default it has seen most often.

The fix is not "write a longer README." Cursor will not always load it. The fix is to expose your structure as queryable memory that Cursor can ask about before it writes a new file.

Cursor has shipped a few features that touch this. None of them close the gap.

Codebase indexing powers retrieval and gives Cursor a working sense of where things live. It improves with familiarity and degrades on cold parts of the repo. It is approximate by design, since the model never sees the full tree at once.

*Project Rules (`.cursor/rules/.mdc`)** let you state topology rules in prose with file globs. They help, but folder conventions are awkward to express in rules, and the rules share prompt budget with everything else.

Native MCP support lets Cursor talk to external servers through .cursor/mcp.json or the Settings UI. This is the cleanest path for exposing live directory and convention data, because MCP returns it on demand instead of stuffing it into the prompt.

You can read Cursor's own MCP setup guide in the official Cursor docs.

For small repos, indexing and Rules suffice. For real, layered codebases, structure drifts.

The deeper issue is that file structure is a contract, not a description. The team agreed that features live in src/features/<feature>/, that hooks colocate, that types go in a types.ts sibling. That contract needs to be queryable, not just present in a README or distributed across thirty rule files. And the same contract needs to apply when a teammate edits the same repo in Claude Code, Cline, or Windsurf.

That is what a cross-tool memory layer fixes: one structural memory, retrievable on demand, shared across every AI editor.

MemoryLake is a cross-model memory layer that sits between you and every AI you use. Instead of relying on Rules and codebase indexing alone, you store your structural contract in a MemoryLake Project, and Cursor retrieves the right slice per edit through MCP.

• Topology as queryable memory. Folder conventions, naming patterns, and import-alias maps live as structured Memories that Cursor can read on demand, instead of being prose stuffed into a rules file.
• 10,000x more context than raw prompting. MemoryLake's retrieval engine reads from billions of tokens of repo decisions and surfaces only the structural slice relevant to the current file. You stop competing with code for prompt budget.
• Portable to every other AI coding tool. The same structural memory works in Claude Code, Cline, Windsurf, and any MCP-aware editor. When a teammate uses a different tool, the contract holds.

MemoryLake scored 94.03% on the LoCoMo long-context benchmark, the top published result as of 2026, with millisecond retrieval and AES-256 end-to-end encryption.

1. Create a project and load your structure. Sign in to MemoryLake, open Project Management, click Create Project, and name it after the repo (for example, "Cursor - web-app structure"). Drop your folder map, alias config, and a canonical sample feature into the Document Drive. Capture the contract ("features live in src/features/<feature>/, hooks colocate, tests use .test.tsx") in the Memories tab.
2. Generate an MCP Server endpoint. Open the MCP Servers tab inside your project, click Add MCP Server, name it "Cursor integration", and click Generate. MemoryLake returns an API key ID, secret, and endpoint URL. Copy the secret immediately, since it is shown only once.
3. Connect Cursor. Cursor has had native MCP support since 2025, which makes this the cleanest path. Add a MemoryLake server entry to .cursor/mcp.json at the repo root (or wire it through Cursor Settings > Features > MCP), paste the endpoint URL and Bearer token, and reload Cursor. Cursor can now query your structural memory before writing or moving any file.