You told Claude Desktop that you use pnpm, that tests go in Vitest, and that you want short answers without a summary at the end. Then you opened Cursor and typed the same three lines again. A week later you changed your mind about the summary and had to change it in two places.
The short answer: keep them in a place both tools can read. Each tool's own settings apply only inside that tool, but both speak MCP, so one memory server connected to each as the same account, plus a one-time instruction in each to check it before answering, leaves one copy to change. Below is where each tool keeps preferences today, why a one-time copy goes stale, and a two-minute check with a control.
Disclosure: I work on Mnemoverse, one of the memory layers that can sit between these two tools.
Claude Desktop keeps preferences for the Claude apps
Anthropic documents several places; these three are where a preference like yours ends up.
Instructions for Claude. "Instructions are account-wide settings that help Claude understand your general instructions that Claude should consider in responses." You set them once under Settings, and they follow your account across the Claude apps.
Project instructions. These "only apply to chats within that project", which is what you want for one codebase's conventions.
Memory. Claude can "remember context from your chats and carry it into new conversations". It is "on by default for Free, Pro, and Max plans on the web, Claude Desktop, and Claude Mobile", and "Each project has its own separate memory space".
All three apply inside Claude's own apps, and none of them is among the rule types Cursor's documentation says it reads.
Cursor keeps preferences for Cursor
Cursor's rules page gives the reason rules exist, under "How rules work": "Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level."
The kind that matches a personal preference is the User Rule. "User Rules are global preferences defined in Customize → Rules that apply across all projects. They are used by Agent (Chat) and are perfect for setting preferred communication style or coding conventions". The same page calls them "Global to your Cursor environment."
Project Rules in .cursor/rules and an AGENTS.md at the repository root travel with the code, so a teammate who clones the repo gets them. That solves the codebase half. It does not reach a Claude Desktop chat: none of the Anthropic pages above says a chat reads .cursor/rules or AGENTS.md.
What Anthropic offers for moving it
Anthropic documents a transfer and frames it as a move: it lets you "import memories from other AI providers into Claude, or export your Claude memory for backup or migration", and the prompt it recommends begins "I'm moving to another service and need to export my data". The flow is a prompt you run in the other assistant, asking it to list every memory it holds, including "Instructions I've given you about how to respond (tone, format, style, 'always do X', 'never do Y')", and then a text box in Claude where you paste the result and click "Add to memory".
The other direction has the same shape: Anthropic suggests asking Claude to "Write out your memories of me verbatim, exactly as they appear in your memory" and pasting the result, which for Cursor means into a User Rule.
Either way it is a one-time copy. The next preference you change is back to two places. The retyping has been given a better interface, not removed.
The one store both tools can reach
Both Claude Desktop and Cursor speak MCP. So there is a place neither of them owns and both can call: a memory server connected to each as the same account. A preference written from Cursor is a record in that store, and a new Claude Desktop chat can read it, because the store is the same one.
Two things have to be true, and they are worth checking rather than assuming.
Both tools are connected as the same account. When the memory belongs to an account on the server, two connections under two accounts are two memories that happen to share a name.
Each tool is told to read before it answers. A connected server does nothing until the model calls it. That instruction is typed once per tool: in Claude Desktop it goes into Instructions for Claude, in Cursor into a rule, either a User Rule for every project or a rule file in the repository. After that, a preference is written once and both tools read it; changing it is one more write, and both tools see that too.
How that looks with Mnemoverse
Claude Desktop. In Anthropic's current steps it is Customize > Connectors, then "+" and "Add custom connector": paste https://mcp.mnemoverse.com/mcp and complete the browser sign-in on first use. There is no config file and no key to paste. Anthropic lists custom connectors on "Free, Pro, Max, Team, and Enterprise plans", with one custom connector on Free; on Team and Enterprise an owner adds it first.
Cursor. The Add to Cursor button on our Cursor page adds the same hosted server to ~/.cursor/mcp.json. The link carries only the server address, no key. Then Cursor Settings → Tools & MCPs → Connect, and you approve in the browser.
Signed in as the same account, the two tools share one memory. Our Cursor page puts it in one sentence: "The memory belongs to the account, not to a tool or a key, so a rule you store in Cursor can be recalled in Claude Code or ChatGPT without re-explaining." Claude Desktop is one more client on the same account.
For that instruction, our agent memory page has a block you paste once into Instructions for Claude and once into Cursor, where our docs show it as .cursor/rules/mnemoverse.mdc with alwaysApply: true. The Claude setting is per account, so each person on a team sets it once for themselves; the Cursor rule file can be committed with the repository.
Check it in two minutes, with a control
- Write one preference in Cursor. Ask the agent to remember that you use pnpm and never npm.
-
Open a new chat in Claude Desktop and ask which package manager you use. The answer should come from a Mnemoverse
memory_readcall you can see in the chat. Claude's own memory and its past-chat search can answer too, the second one also as a visible tool call, so check the tool name. - Control. Open one more new chat, switch Mnemoverse off for it under + > Connectors, and ask the same question. It should not know. If it still says pnpm, Claude's own memory or instructions hold it, and step 2 proved nothing: repeat steps 1 and 2 with a preference you have never given Claude.
-
Change it once. Tell Cursor you switched from pnpm to Bun. Ask Claude Desktop again: Bun, again from
memory_read. One edit, both tools.
If step 2 comes back empty, look at the tool call. No memory_read at all: check that Mnemoverse is on for that chat under + > Connectors and that the instruction is saved. A memory_read that returns nothing: the two tools are signed in as different accounts (troubleshooting).
The full review checks six memory services against the same mechanism and names the ways sharing quietly stops. Which of your preferences do you currently keep in more than one tool?
Setup for Claude Desktop and Cursor is in our docs, and the MCP server package on npm is open source (MIT): github.com/mnemoverse/mcp-memory-server.
Top comments (3)
This is a practical problem that gets overlooked as AI tools become part of everyday workflows. I like the idea of separating tool-specific instructions from shared preferences. Otherwise, the same context gets copied everywhere and eventually becomes outdated. One source of truth makes the workflow much easier to maintain, especially when working across multiple AI coding tools.
Edward, "the retyping has been given a better interface, not removed" is the
sentence I underlined twice, because it names the failure my whole toolkit
exists to catch: a one-time copy is a stamp without an id. The export-and-paste
flow carries the content of a preference and none of its history, so the next
edit does not fail anywhere — it simply leaves two records, one of them
silently wrong. That is my stale-anchor problem in settings form: a verbatim
copy can never tell you it is out of date, because nothing in it points back
to the source that would prove it. The shared store fixes exactly this, and
not by being more convenient: a record read live from one store is a stamp
that still carries its id, so a change is one write and every reader sees the
new version or sees nothing.
What makes this post engineering rather than advice is step 2's "check the
tool name." A correct answer of "pnpm" can be earned by three different
paths — a Mnemoverse memory_read, Claude's own memory, a past-chat search —
and a single green answer merges all three. That is the twin green lie one
layer down: the conclusion is right and the precondition is unknown, so the
next change to any one path will look like a regression in another. Requiring
the visible tool call is requiring the route tag: the answer must carry the
proof of which source earned it, the same way every verdict in my golden set
carries the embedder that earned it. And step 3 is the counterfactual pair
made into a setup checklist — same question, connector off, assert absence —
with your own rule from the feedback post doing the work: a zero without a
control proves nothing, and a "pnpm" with the store off proves step 2 measured
Claude's memory, not the sharing. Your disclosure sits next to a control a
reader can run against your own product, which is the only shape of vendor
honesty I trust.
The line I am stealing with credit is "two connections under two accounts are
two memories that happen to share a name." Mikhail Makeev's ticker post
documented the same failure one layer up: his old MCP search resolved Jane
Street to Janel Corp, and in his words the request succeeded but the subject
was wrong. Name equality is not identity in news search, in memory accounts,
or in chunk ids; the account is the id here, the way the retrieved path is the
id in my rows. It is also why your two preconditions — same account, and each
tool told to read before answering — belong in the setup rather than in the
marketing: they are the assertions the sharing depends on, and an unasserted
precondition is exactly how a demo becomes two memories with one name.
One bridge from this week's other thread, because it lands here cleanly:
Mikhail's search API reports whether it matched strictly, broadened, or found
nothing, and his rule is that the explanation travels with the rows. Your
step 2 asks the human to check the tool call; the structural version is the
same rule — the answer should carry its source mode the way his pages carry
theirs, so a reader can tell a memory_read answer from a
fell-back-to-Claude's-own-memory answer without opening the transcript. Until
a client stamps that, "check the tool name" is the honest manual gate, and
your troubleshooting branch — no memory_read at all versus a memory_read that
returns nothing — is already the mode enum in disguise: instruction missing
versus account mismatched, two different repairs for two different silences.
So the question I genuinely want your read on, continuing your own control
rather than adding a new one: the one instruction that cannot live in the
shared store — the per-tool rule that says read before answering — is the
precondition of the entire loop, and it is the one record the loop cannot
assert about itself. If someone deletes the .mdc rule or edits the
Instructions line, sharing degrades to one direction and every answer still
looks green, because Claude's own memory keeps answering. Is there a shape for
a canary on the bootstrap layer — a memory only the store holds, asked from
each tool on a schedule, whose silence pages a human the way my stale rows
reorder a queue — or is the honest answer that the bootstrap instruction is
the irreducible outside, stamped by hand at setup and re-checked by hand
forever, the way my first embedder tags were? Asking because Article 3 now
cites this post for the copy-versus-store axis, and the draft's methods
section has a blank space exactly where a bootstrap canary would go. The
rank-stamp commit lands ahead of the draft, as promised, so section 3 and the
code will agree in the version you diff next.
The bootstrap can be checked by a canary, with one condition that decides whether it measures the instruction or something else: its answer has to be new on every run. A fixed canary fact stops being a canary the first time the tool's own memory or a past-chat search picks it up, and from then on it answers correctly with the store off, which is the twin green lie again. So the job writes a fresh value to the store first, asks each tool for it, and asserts on the memory_read call in that tool's transcript returning the value just written, not on the answer text.
Where a client can be driven from a script, such as Claude Code in print mode, that job runs on a schedule and its silence can page someone; allow the memory tool in advance there, because a print-mode run denies any call that would wait for approval. A desktop app with no scriptable mode stays a hand check, so the honest answer is per tool rather than one answer for the whole setup. The job should also report which silence it saw, because a missing memory_read and an empty one need different repairs: the connection or the instruction in the first case, the account in the second.