guides

One state folder, every AI tool

Claude Code reads CLAUDE.md. Cursor reads .cursorrules. Codex reads its own files. Connect all three to one MCP server and stop repeating yourself.

The silo problem

Each AI coding tool keeps its own rules file and its own memory. Knowledge does not flow between them. You describe your stack to Claude Code, then again to Cursor, then again to Codex. When the session ends, each tool forgets what it learned.

The result: duplicated context, inconsistent knowledge, and wasted tokens. Your tools never build on each other's findings.

Why MCP fixes this

Every major AI coding tool speaks MCP (Model Context Protocol). One server, many clients. The server holds the state. All clients read and write the same files.

gcontext is an MCP server that serves a folder of plain text files as persistent state. Install it, point your tools at it, and they share one memory.

Step 1: Start the server

Install gcontext, create an instance, and start the server. The server prints its URL on startup (default http://127.0.0.1:4242/mcp).

The server exposes four tools: read_file, write_file, list_dir, and grep. State lives in the instance folder on disk.

terminal
$ uv tool install gcontext-ai
$ gcontext init my_project
$ gcontext up my_project

Step 2: Connect Claude Code

Register the MCP server with Claude Code. Use the HTTP transport.

Claude Code can now call read_file and write_file on the shared state folder.

terminal
$ claude mcp add --transport http my_project http://127.0.0.1:4242/mcp

Step 3: Connect Cursor

Add the server to your project-level .cursor/mcp.json (or the global Cursor MCP config).

Restart Cursor or reload the MCP config. The same tools are now available in Cursor.

mcp.json
{
"mcpServers": {
"my_project": {
"url": "http://127.0.0.1:4242/mcp"
}
}
}

Step 4: Connect Codex

Codex supports MCP servers through ~/.codex/config.toml.

Codex now reads from the same state folder as Claude Code and Cursor.

~/.codex/config.toml
[mcp_servers.my_project]
url = "http://127.0.0.1:4242/mcp"

Step 5: Prove it

Write a fact from Claude Code. Read it from Cursor. The content is the same because both tools hit the same server.

The state folder is the single source of truth. Any tool that connects to the server reads the latest version of every file.

terminal
Claude Code: writing to modules/stack/index.md
> "This project uses Next.js 15, Python 3.12, and PostgreSQL."
Cursor: reading modules/stack/index.md
> "This project uses Next.js 15, Python 3.12, and PostgreSQL."

What to keep in shared state vs per-tool files

Put project architecture, API quirks, design decisions, debugging learnings, and connection configs in shared state. Keep Cursor-specific settings, Claude Code skills, and Codex instruction overrides in per-tool files.

The rule: shared state holds knowledge about the project. Per-tool files hold configuration for the tool itself. Keep the state folder focused on what every tool needs to know.

Questions

Can Claude Code and Cursor share memory?

Not natively. Each tool has its own rules files. Connect both to the same gcontext MCP server and they read the same state.

Does this work with Claude Desktop?

Yes. Add the server URL to your claude_desktop_config.json under mcpServers with the same format as the Cursor example.

What happens if two tools write at the same time?

Last write wins. In practice this is rare because you use one tool at a time. For safety, keep per-tool scratch files and share only distilled knowledge.

Related

Claude Code memory
What persists and what does not in Claude Code
What is agent state?
Definition and management patterns
Stateful MCP servers
The pattern behind gcontext
Agent registry
Install and share agents
One memory, every tool

Install gcontext. Connect your tools. Stop explaining your project twice.

View on GitHub