claude-checkpoint-mcp

<img src="plugin/.claude-plugin/icon.png" alt="" width="56" height="56" align="right">

# claude-checkpoint-mcp

**Save your Claude Code session state locally, so a crash, `/clear`, or context limit doesn't make Claude rebuild context from scratch.**

[![License: MIT](https://img.shields.io/badge/license-MIT-blue.svg)](LICENSE)
[![Node.js ≥ 20](https://img.shields.io/badge/node-%E2%89%A520-339933.svg)](https://nodejs.org)
[![MCP](https://img.shields.io/badge/MCP-stdio-8A2BE2.svg)](https://modelcontextprotocol.io)
[![M8ven Score](https://m8ven.ai/badge/mcp/tenlean/claude-checkpoint-mcp)](https://m8ven.ai/mcp/tenlean/claude-checkpoint-mcp?s=readme)

`claude-checkpoint-mcp` is a local [Model Context Protocol](https://modelcontextprotocol.io) server with two tools:

- `save_session_checkpoint` writes your session's working state to a small JSON file in the project.
- `load_session_checkpoint` turns that file back into a compact resume brief.

It runs entirely on your machine. Nothing is sent anywhere.

---

## Contents

- [Why: stop paying twice for the same context](#why-stop-paying-twice-for-the-same-context)
- [How it works](#how-it-works)
- [Installation](#installation)
- [Configuration](#configuration)
  - [Claude Code](#claude-code)
  - [Claude Desktop](#claude-desktop-claude_desktop_configjson)
  - [Other MCP clients](#other-mcp-clients)
- [Usage](#usage)
- [Tool reference & examples](#tool-reference--examples)
- [The `.claude-checkpoint` file](#the-claude-checkpoint-file)
- [Security & privacy](#security--privacy)
- [Troubleshooting](#troubleshooting)
- [Development](#development)

---

## Why: stop paying twice for the same context

A long Claude Code session builds up a lot of context:
- what you're trying to do;
- which approaches already failed;
- which files matter;
- which test is still red.

Several things can wipe that out mid-task:
- a terminal crash, SSH drop, or laptop sleep;
- running out of context window;
- a `/clear` to get a fresh window.

The next session starts cold. To get back to where you were, Claude has to rebuild that context:

- **Re-reading files** to work out what was changed and why. Every file read is input tokens.
- **Re-running exploration**: `grep`, `git diff`, `ls`, test runs, all just to rediscover state.
- **Re-explaining.** You retype the goal, the constraints, and the dead ends, or Claude rediscovers the dead ends the hard way.

Each of those turns resends the growing conversation as input, so the cost compounds.

**`claude-checkpoint-mcp` swaps that rebuild for one small, structured read:**

| | Without a checkpoint | With `load_session_checkpoint` |
|---|---|---|
| Restoring the goal & constraints | You retype them, or Claude infers them | One section of the brief |
| Knowing what's done vs. pending | Re-derived from code and git | Task list with statuses |
| Knowing which files matter | Broad re-reading | Exact list of touched files, with notes |
| Knowing what changed since | Re-read everything to be safe | **Only files whose content actually changed** are flagged |
| Remembering failed attempts | Often repeated | Recorded under *Decisions & gotchas* |

The resume brief for a typical session is about **1.2 KB of markdown**, a few hundred tokens. The [example below](#example-resume-brief) is real output at that size.

The biggest saving comes from **drift detection**. At save time, the server records a content hash for every file with uncommitted changes. On load, it compares those hashes against the working tree and tells Claude exactly which files changed after the checkpoint. Everything else in the brief can be trusted as-is, so Claude re-reads only what it has to.

---

## How it works

```
  Session 1                                     Session 2 (after crash / /clear)
  ─────────                                     ────────────────────────────────
  Claude ──save_session_checkpoint──┐       ┌──load_session_checkpoint── Claude
         goal, tasks, summary,      │       │   compact markdown brief
         next steps, decisions,     ▼       │   + "changed since checkpoint"
         files, commands      ┌─────────────────────┐
                              │ <project>/          │
     server adds:             │ .claude-checkpoint  │◀── git: branch, HEAD,
     git branch/HEAD,         │ .claude-checkpoint  │    dirty files + hashes
     dirty files + hashes,    │   .prev (backup)    │
     redacts secrets          └─────────────────────┘
```

- **Claude supplies the meaning**: the goal, progress, decisions, next steps, and which commands mattered.
- **The server supplies the facts**: git branch and HEAD, every uncommitted or untracked file with its content hash, and timestamps.
- **The server instructions teach Claude when to act.** Claude is told to load at the start of a session and to save after milestones, before risky operations, and when the conversation gets long. It doesn't need to be prompted every time.

---

## Installation

Requirements: **Node.js 20+** and **git**. Git is optional, but without it you lose drift detection.

```sh
git clone https://github.com/tenlean/claude-checkpoint-mcp.git
cd claude-checkpoint-mcp
npm install
npm run build
```

The server entry point is now at `dist/index.js`.

---

## Configuration

### Claude Code

**As a plugin (easiest).** This repo is also a Claude Code plugin marketplace. You don't need to clone or build anything:

```sh
claude plugin marketplace add tenlean/claude-checkpoint-mcp
claude plugin install claude-checkpoint-mcp@tenlean
```

Restart Claude Code, then `/mcp` should show `plugin:claude-checkpoint-mcp:claude-checkpoint` as connected.

**Manual setup.** If you cloned the repo, register the server once for your user account, so it's available in every project:

```sh
# Run from the claude-checkpoint-mcp directory
claude mcp add --scope user checkpoint -- node "$PWD/dist/index.js"
```

> **Use an absolute path.** A user-scoped server is launched from whichever project you open Claude Code in. A relative path like `./dist/index.js` would resolve against *that* project, not this repo. `"$PWD/dist/index.js"` expands to the absolute path when you run the command, which is what gets saved.

Check that it's registered:

```sh
claude mcp list
```

Inside a session, `/mcp` should show `checkpoint` as connected.

**Project-scoped alternative.** To share the server with a team through version control, add it to the project's `.mcp.json`:

```json
{
  "mcpServers": {
    "checkpoint": {
      "command": "node",
      "args": ["/absolute/path/to/claude-checkpoint-mcp/dist/index.js"]
    }
  }
}
```

Either way, add the checkpoint files to the project's `.gitignore`, or to your global gitignore:

```gitignore
.claude-checkpoint*
```

### Claude Desktop (`claude_desktop_config.json`)

Open the config file:

| OS | Path |
|---|---|
| macOS | `~/Library/Application Support/Claude/claude_desktop_config.json` |
| Windows | `%APPDATA%\Claude\claude_desktop_config.json` |

Add the server under `mcpServers`, using the absolute path to your local build:

```json
{
  "mcpServers": {
    "checkpoint": {
      "command": "node",
      "args": ["/absolute/path/to/claude-checkpoint-mcp/dist/index.js"],
      "env": {
        "CHECKPOINT_PROJECT_ROOT": "/absolute/path/to/your/project"
      }
    }
  }
}
```

Restart Claude Desktop after saving the file.

> Claude Desktop has no notion of a "current project". Use `CHECKPOINT_PROJECT_ROOT` to set the default project, or have Claude pass `projectRoot` on each call (*"save a checkpoint for /home/me/code/my-app"*). See [project root resolution](#how-the-project-root-is-chosen).

### Other MCP clients

Any MCP client that supports the stdio transport can run the server:

```sh
node /absolute/path/to/claude-checkpoint-mcp/dist/index.js
```

---

## Usage

The server's built-in instructions cover the common cases automatically. You can also ask Claude directly.

**Save**:
- *"Checkpoint our progress."*
- *"Save a checkpoint before you run the migration."*
- *"Update the checkpoint. Merge in what we just did."*

**Resume** (in a fresh session):
- *"Resume where we left off."*
- *"Load the checkpoint and continue."*

### Example resume brief

This is real output from `load_session_checkpoint`. In the scenario, one file was committed unchanged after the save, and a teammate then edited `session.ts`:

```markdown
# Resuming: my-app (checkpoint saved 2m ago, 2026-10-08 02:23:55 UTC)
Branch `feat/github-oauth` @ b2ef1b591 (uncommitted changes)

## Goal
Add GitHub OAuth login with persistent sessions

## Tasks
- [x] OAuth callback route
- [~] Session cookie persistence
- [ ] Logout endpoint

## Where things stand
Callback exchanges the code and creates a session, but the cookie is dropped on reload. Suspect SameSite/secure flags in dev.

## Next steps
1. Set sameSite: 'lax' and secure only in production in src/auth/session.ts
2. Re-run npm test -- auth
3. Start the logout endpoint

## Decisions & gotchas
- Use iron-session, not express-session (needs edge runtime support)
- Don't mock the GitHub API in e2e tests; use the recorded fixtures in test/fixtures

## Files touched (3)
- src/auth/session.ts (M) — cookie options
- src/auth/callback.ts (M)
- src/auth/session.spec.ts (??)

## Recent commands (last 2, oldest first)
- ✓ `GITHUB_CLIENT_SECRET=«redacted» npm run dev`
- ✗ exit 1 `npm test -- auth` — 2 failing in session.spec.ts: cookie missing after reload

## Since this checkpoint
- 1 new commit(s) on HEAD
- ⚠ Changed after the checkpoint, re-read before editing: `src/auth/session.ts`
```

`callback.ts` was committed after the save, but its content didn't change, so it isn't flagged. Only `session.ts` needs to be re-read.

Task markers: `[x]` done · `[~]` in progress · `[ ]` pending · `[!]` blocked.

---

## Tool reference & examples

### `save_session_checkpoint`

Writes `<projectRoot>/.claude-checkpoint`.

| Parameter | Type | Required | Description |
|---|---|:-:|---|
| `goal` | `string` (≤ 50