Give Cursor Persistent, Project-Aware Memory

The problem: Cursor doesn't remember the last time you worked on this repo

Cursor is good at reasoning about the code that's open right now, but close the editor and reopen the same repo tomorrow, and it has no memory of the decisions you made yesterday — why you picked one approach over another, what you already ruled out, what the team agreed on in a related conversation. You end up re-explaining the same project context every session, or hoping it's still in your head.

It gets worse across projects. If you work in more than one repo, a generic memory layer that doesn't know which project it's for is nearly as bad as no memory at all — a fact from one codebase surfacing while you're working in an unrelated one is noise, not help. What Cursor needs isn't just persistent memory, it's memory that knows which project it belongs to.

This guide covers connecting Cursor to a memory server that does both: it persists across sessions, and it's scoped per repository automatically.

How it works

Great Arrow Digital's MCP server groups memory into workspaces, and workspaces have a kind — one of them, REPO, exists specifically for this case. REPO workspaces are auto-provisioned from the repository's own URL: when a connecting client sends an X-Repo-URL header (or the setup is done via the CLI's gad-init.sh script), the server creates or reuses a workspace bound to that exact repo. Work you do in one repository lands in that repo's own workspace; switch to a different repo and you're in a different workspace, with its own memory.

The first time a REPO workspace is created, the connecting agent is prompted (via the MCP initialize response) to seed a bounded starting snapshot into memory — the README, the project's file structure, key manifest files, and recent git log — so a brand-new project workspace has some baseline context instead of being empty.

Cursor connects as a file-based client authenticated with a personal API token, using either a native one-click deeplink or a JSON config file.

Setting it up

1. Create your account. Sign up at /sign-up — no credit card required for the 14-day trial.
2. Open Cursor in the repo you want scoped memory for, then go to /install and choose Cursor.
3. Click the one-click install link. Cursor's native deeplink opens its own "Install MCP server?" confirmation dialog and writes the config for you — no terminal, no file editing. Confirming it connects the server with your token and the headers Cursor needs.
4. Let the first-connect prompt run. On a brand-new repo, the connecting agent may be asked to seed an initial snapshot (README, structure, manifest, recent git log) into memory. This is a one-time step per repo and happens automatically as part of the conversation — not a separate manual task.
5. If the remote connection errors with no tools, use the fallback: the install page's manual config option includes a local stdio-proxy config for Cursor that sidesteps that specific failure mode without giving up any functionality.
6. Repeat per repository. Each repo you connect Cursor from gets its own REPO workspace automatically — you don't need to create or name anything by hand.

What this gives you day to day

Once connected, asking Cursor about a past decision in the current repo searches that repo's own memory — not a global pool mixed with every other project you've touched. Switching repos switches which workspace Cursor is reading from and writing to, without you managing that scoping manually. And because the underlying memory is the same MCP layer other clients use, anything stored from Cursor is available to another connected client working in the same repo, and vice versa.

This matters most if you work across several codebases in a given week. Without per-repo scoping, a memory server either mixes everything into one pool (so a fact about repo A shows up while you're debugging repo B) or forces you to manage separate accounts or workspaces by hand. REPO workspaces solve this at the connection layer instead: the repo URL itself is the key, so the right scoping happens automatically the moment Cursor connects from inside that repo — you never have to remember to switch anything.

If you set up Cursor through the CLI installer rather than the deeplink — using gad-init.sh from a terminal inside the repo — the same auto-provisioning applies. The script identifies the repo the same way the deeplink connection does, so the workspace you land in is consistent regardless of which install path you used.

One workspace per repo, per account

The auto-provisioned REPO workspace is keyed to your own account and the repo's URL, so connecting Cursor from the same repository always resolves back to the same workspace for you specifically — reconnecting, switching machines, or reinstalling Cursor doesn't fragment your project's memory into separate pools. If a teammate wants to share that project's memory with you, that's a normal workspace invite, the same as any other workspace on the platform — REPO workspaces aren't a special case there, just a special case for how the workspace itself gets created in the first place.

Where to go next

If your team tracks work in Jira alongside the codebase, Cursor MCP Server for Jira covers connecting that integration so Cursor can search ticket context too. If you're extending memory beyond Cursor to other clients, One Memory Across Every AI Client covers the general pattern and the full client list.