I’ve been switching between a few AI coding tools recently and the context/memory part is starting to annoy me.
Claude Code, Codex, Cursor, Windsurf, etc. all seem to have slightly different ways of handling project context, rules, memories, notes, and session history.
For people who use more than one of these seriously, what’s your current setup?
Do you just keep markdown files in the repo, use rules, use an MCP memory server, Obsidian/Notion, or something custom?
Mostly curious what actually works in daily use, because I feel like I keep re-explaining the same things between tools.
Hey, good question. Everyone really builds their own Frankenstein setup here. I’ll share what usually works and what I see from users.
Portable base setup (minimum pain when switching tools)
Keep an AGENTS.md at the repo root. Codex, Claude Code, Cursor, and some others respect it. It’s a good place for what the project is, how to build and test it, and coding conventions. Cursor reads it automatically.
Keep commands and scripts in package.json or Makefile or justfile, not in prompts. Then have AGENTS.md link to them, so there’s less drift.
Cursor-specific, but compatible in spirit
Use .cursor/rules/*.mdc for more structured rules with globs. They apply automatically based on file type. Docs: Rules | Cursor Docs
Practical observation
Most users who actually stop rewriting the same stuff keep a single source of truth in the repo, like AGENTS.md plus links to scripts and docs. Then they keep tool-specific files as a thin layer on top. Markdown in Obsidian or Notion is nice for personal notes, but as agent context it gets outdated fast. I’ve also seen this CLI for drift checks, which helps catch when instructions don’t match the real code: Built a small CLI to detect AGENTS.md drift (missing commands, dead paths, conflicting nested files)
Curious what others are doing. Is anyone actually running an MCP memory server in production across tools?
The AGENTS.md + real scripts/docs as source of truth makes a lot of sense. I’ve noticed the same thing: once context lives only in prompts or memory, it gets stale fast and then agents confidently follow old instructions.
The drift-check idea is especially interesting. In your experience, what breaks first?
AGENTS.md gets stale
tool-specific rules diverge
old memories become wrong
commands/paths change
agents don’t load the right context at all
Also curious: have you seen anyone actually run MCP memory across multiple tools in a reliable way, or is it still mostly experimental/local setups?
I’m mostly trying to improve my own workflow right now, so practical ugly details are more useful than polished theory.
Commands and paths change. This is the most common case. Someone renames a script in package.json, moves a config file, switches from pnpm to bun, but AGENTS.md still has the old instruction. Agents follow it with confidence, and you waste an extra cycle trying to figure out why the build command doesn’t work.
AGENTS.md gets outdated. This is second place. Users update code and forget the docs. The drift utility I mentioned earlier exists for exactly this reason, it’s the most boring and most common failure mode.
Old memories become wrong. It happens, but usually with a smaller blast radius. A memory like “we use Jest” survives a migration to Vitest and quietly poisons recommendations. It’s worth cleaning up memories every few weeks.
Rules tied to specific tools drift apart. This is a slow burning issue. You tweak a rule for Cursor and forget to mirror it in the equivalent for Claude Code or Codex, and different tools start behaving differently. This is less “it broke” and more “why does Cursor do X, but Codex does Y”.
Agents don’t load the right context. This is more of a constant background tax than a sudden break. Usually fixed with more explicit glob patterns in .cursor/rules/*.mdc or by passing files directly in the prompt.
If I had to pick one rule of thumb, anything that duplicates info already in code or config will go stale over time. Anything that just points to that info tends to stay correct.
About MCP memory shared between tools, honestly right now it’s mostly experimental or one off setups. I see users run local stuff like Mnemosyne: A local, persistent memory MCP server for Cursor or Cursor-memory — Persistent, Searchable Memory for Cursor AI and get real value within a single workflow. Cross tool, reliable, team memory is a totally different beast. MCP support quality varies across tools, and memory that one tool writes and another reads only works if both are disciplined about when to write and when to retrieve, and in practice that isn’t there yet. I haven’t seen a setup I’d call production grade across multiple tools. If anyone reading has one, I’d genuinely love to hear about it.
For your workflow, the boring answer will probably win: AGENTS.md plus scripts as the source of truth, a small drift check in CI, clean up memories from time to time, and treat MCP memory as a nice bonus, not the foundation of the system.