Ctxfile MCP server
{
"mcpServers": {
"ctxfile": {
"command": "npx",
"args": [
"-y",
"ctxfile@latest"
]
}
}
}{
"mcpServers": {
"ctxfile": {
"command": "npx",
"args": [
"-y",
"ctxfile@latest"
]
}
}
}{
"mcpServers": {
"ctxfile": {
"command": "npx",
"args": [
"-y",
"ctxfile@latest"
]
}
}
}{
"servers": {
"ctxfile": {
"command": "npx",
"args": [
"-y",
"ctxfile@latest"
]
}
}
}{
"mcpServers": {
"ctxfile": {
"command": "npx",
"args": [
"-y",
"ctxfile@latest"
]
}
}
}file .mcp.json (in your project root)file claude_desktop_config.jsonfile ~/.cursor/mcp.jsonfile .vscode/mcp.jsonfile ~/.codeium/windsurf/mcp_config.jsoninstall npx -y ctxfileversion 0.5.0
What it does
ctxfile is a local-first MCP server that captures your project's working state—plan documents, key files, git status, and conversation history—into a structured context object. It lets you save a session in one AI agent and resume it in another without losing context, keeping everything on your machine by default.
- Load your full project context into any MCP-speaking agent (Claude, Cursor, Codex) with a single call instead of re-explaining your work.
- Save your current session and continue it in a different agent or on a different machine while preserving decisions and open items.
- Export a static context snapshot for use with hosted coding agents or CI systems that cannot access your local machine.
Tools this server exposes
| Tool | Does |
|---|---|
| get_context | Returns a structured ContextObject containing plan docs, ranked key files within a token budget, git state, and optional Notion pages or LLM summaries. |
| save_session | Stores an agent-written summary of the current conversation for later retrieval. |
| continue_thread | Retrieves merged conversation history with provenance labels to hand to the next agent, resuming work across different harnesses or providers. |
| ingest_context | Schema-enforced endpoint for any agent harness without a native parser to load context using a prompt as adapter. |
Before you enable it
An MCP server runs with whatever access you give it. Start with a development account rather than production, and check which tools the server exposes before you let an agent call them unattended.