Shared memory for Claude Code

Why Claude Code teams add threadctx

• It closes the loop between terminal sessions. Claude Code's context resets between sessions. When your agent resolves a non-obvious bug — a flaky test, a misconfigured retry policy, a decision about why a service is shaped the way it is — threadctx lets it write that down once, so the next session (yours or a teammate's) doesn't rediscover it from scratch.
• It works the same in the terminal as it does in Cursor. MCP is a portable protocol. The exact same threadctx server and the exact same memory back a teammate's Cursor agent panel — so a fix your Claude Code agent learns is visible to a Cursor user on the same repo, not just to other Claude Code users.
• Recall is inline, not a separate step. Whenmemory_queryreturns a hit, it appears in Claude Code's normal tool-result flow with a short attribution footer (· via threadctx) — plain text that survives copy-paste into Slack threads and CI logs.

Add it to Claude Code

Edit ~/.claude/mcp.json (or run claude mcp add) and paste this block. For local mode, drop the env block entirely — no key needed.

{
  "mcpServers": {
    "threadctx": {
      "command": "npx",
      "args": ["-y", "threadctx-mcp"],
      "env": {
        "THREADCTX_MODE": "cloud",
        "THREADCTX_API_KEY": "tctx_..."
      }
    }
  }
}

Claude Code will call memory_query before risky or repeated work and memory_write after resolving something non-obvious — this isn't just a hopeful tool description. The first time threadctx starts in a repo it automatically adds a "check team memory" instruction to your CLAUDE.md, and the same instruction is sent to Claude Code directly over MCP's handshake. No setup step, nothing to remember to run.

Curious what's stored on your machine? Run npx threadctx-mcp list. Want to trigger or inspect the project-rules block explicitly (or opt out with --no-rules)? Run npx threadctx-mcp init.