Your agents learn.
Your team forgets.
Your Claude Code agent and your teammate's Cursor agent don't know what the other one already figured out. threadctx is the shared memory layer that fixes that — one MCP server, your whole team, every tool. So “we tried that, it broke prod” is something every engineer's agent knows.
$ npx threadctx-mcpFree & open source for solo work. No signup, no account, runs locally.
Works in the agents your team already uses
Every agent starts from zero. Every time.
AI agents are brilliant in the moment and amnesiac across sessions. The hard-won lesson one engineer's agent learned on Tuesday is invisible to a teammate's agent on Wednesday — even in the same repo, even about the same bug.
Without threadctx
- · The same prod incident gets re-discovered three times.
- · Cursor doesn't know what Claude Code decided last sprint.
- · Architectural context lives in one person's terminal history.
- · Onboarding an agent = onboarding from scratch.
With threadctx
- · One agent learns it — every agent on the repo knows it.
- · Decisions and fixes carry across tools and teammates.
- · Recall happens automatically, before risky work.
- · Memory compounds instead of resetting.
One layer. Two tools. Zero rewiring.
threadctx is a Model Context Protocol server. It drops into any MCP-capable agent and gives them a shared place to read and write team memory.
Install in 30 seconds
Add one MCP server to Claude Code or Cursor. Same package, same config block. No SDK, no rewrite.
Agents write what they learn
When an agent resolves a non-obvious bug or makes a call, it stores the learning — scoped to your repo.
Every agent recalls it
Before risky or repeated work, agents query the shared memory and surface what the team already knows.
Add to Claude Code & Cursor
{
"mcpServers": {
"threadctx": {
"command": "npx",
"args": ["-y", "threadctx-mcp"],
"env": {
"THREADCTX_MODE": "cloud",
"THREADCTX_API_KEY": "tctx_..."
}
}
}
}Surfaced where work happens
The same short · via threadctx attribution everywhere, so the value is legible the third time a teammate sees it.
Inline in your terminal
Recalled memory lands in the normal tool-result flow with a consistent attribution footer — plain text that survives copy-paste into Slack and CI logs.
In the agent panel
The same shared memory, surfaced in Cursor’s agent UI with the same attribution string. One brand, recognizable everywhere your team works.
On the pull request
Opt-in PR comments flag when a change touches a service the team has hit trouble with before — visible to teammates who haven’t installed anything yet.
Free for solo. Paid when it's shared.
The moment a second teammate needs the same memory is the moment it becomes a Team plan. The loop and the paywall are the same event — by design.
Local
For solo work. Open source.
- ✓Runs entirely on your machine
- ✓SQLite-free JSON store, no native build
- ✓No account, no signup, no network calls
- ✓Works in Claude Code and Cursor
- ✓Per-repo keyword recall
Team
Shared memory across everyone on the repo.
- ✓Everything in Local, shared across the team
- ✓Real semantic search (vector recall)
- ✓GitHub-org scoped, one key per team
- ✓Unlimited fair-use queries
- ✓Attribution surfaced in every agent
- ✓Email support
$108/seat billed annually
Enterprise
SSO, audit log, self-hosted / VPC.
- ✓Everything in Team
- ✓SSO + SCIM
- ✓Audit log & data residency
- ✓Self-hosted / VPC deployment
- ✓Priority support & SLA
Team plan includes a 14-day free trial. Fair-use query limits, no per-call billing. Cancel anytime, self-serve.
Questions
How is this different from local-only agent memory tools?+
Local-first tools give one developer’s agent a memory on their own machine. threadctx is built for the team case: shared memory across people and across tools (Claude Code, Cursor, anything that speaks MCP). Solo and local is free and open source here too — the paid product is the shared layer.
Do I have to send my code anywhere?+
No. threadctx stores the short learnings your agents choose to write — decisions, fixes, gotchas — not your source code. Local mode never makes a network call beyond your own LLM provider. Cloud mode stores only those memory entries, scoped per repo and per team.
Does it work with both Claude Code and Cursor?+
Yes — identically, and well beyond those two. MCP is a portable open protocol, so the same package and config work in any MCP client. On first start threadctx also writes the "check team memory" instruction into the rule files your repo actually uses — AGENTS.md (the cross-tool standard read by Copilot, Cursor, Windsurf, Zed, Codex, Aider and ~24 more), CLAUDE.md, and tool-specific files for Copilot, Windsurf, Cline, and Gemini when it detects them. That cross-tool sharing is the entire point.
What does the Team plan actually unlock?+
Shared, semantic memory across everyone on the repo, with real vector recall instead of local keyword matching. Local mode stays free forever for solo use.
Can we self-host?+
Yes. The cloud backend is one Next.js app you can deploy yourself; point the MCP server at it with one environment variable. Enterprise adds SSO, audit logging, and VPC deployment.
What is an MCP server?+
MCP (Model Context Protocol) is an open standard that lets AI agents call external tools — read data, write data, call APIs — through a common interface. threadctx is an MCP server: it exposes two tools, memory_write and memory_query, that any MCP-capable agent (Claude Code, Cursor, and others) can call.
How do I make sure my agent actually reads the shared memory?+
MCP tools are pull-based — no server can force a tool call — so threadctx stacks several layers instead of relying on one. The MCP handshake itself carries a "check memory before, write after" instruction to every connecting client automatically. The server also auto-adds that same instruction to your project rule files (AGENTS.md and CLAUDE.md always; Copilot, Windsurf, Cline, and Gemini files when those tools are detected) the first time it starts in a repo — no setup step required. And the tool descriptions themselves prompt proactive use. All of it is idempotent; run `npx threadctx-mcp init` any time to trigger and see it explicitly.
What if an agent forgets to write a memory at all?+
Then git history still catches it. `npx threadctx-mcp capture` reads the commits landed since it last ran, uses your own LLM key to distill the reusable decisions and gotchas (skipping trivial commits), dedups against what is stored, and writes the rest — no agent involvement required. Drop the included GitHub Action in and every merged PR is captured automatically. It is off until you set THREADCTX_CAPTURE_ENABLED=1, and it calls your LLM provider directly, never through us.
How do I see or edit what has been stored?+
For local mode, `npx threadctx-mcp list` prints what your agents wrote to your machine (--all for every repo, --full, --json). It is read-only and makes no network calls — the store is a plain JSON file at ~/.threadctx/local.json you can inspect or delete anytime. For team (cloud) memory, the dashboard at threadctx.dev/dashboard lets anyone on your team browse, search, edit, and prune memory in the browser — sign in with your team API key.
Give your team's agents a shared memory.
Start free locally in 30 seconds. Turn on shared memory for the team when you're ready.
$ npx threadctx-mcp