Anchor

Anchor watches AI coding agents work on your codebase, records what they did and why, and tells you which attempt actually worked — measured by your test suite, not by reading diffs.

Everything is local. No accounts, no cloud, no telemetry.

Download

Download for Windows → (Anchor_0.1.0_x64_en-US.msi, 7 MB)

Double-click the .msi and it installs to C:\Program Files\Anchor\.

Windows will show "Windows protected your PC" the first time. That is because the installer is not code-signed — a signing certificate costs several hundred dollars a year, and this is a free project. Click More info → Run anyway. If you would rather not, build from source instead; the instructions are below and the result is identical.

Windows only for now. The code is cross-platform but macOS and Linux have not been built or tested, so there is nothing honest to hand you yet.

Related MCP server: triage-agent-mcp

The problem

You ask an agent to fix a bug. It fixes it. You ask again in a fresh session and get a different fix. Both look reasonable. Both compile. You have no way to tell which one is right except by reading them closely and guessing.

Anchor removes the guessing. Run the task three times on three branches, and it executes your real test suite against each one in an isolated git worktree:

attempt 1   6 passed  0 failed   ← merge this
attempt 2   3 passed  3 failed   test_streak_resets, test_tz_rollover, test_grace_day
attempt 3   5 passed  1 failed   test_tz_rollover

No model decides pass or fail. That verdict is your test runner's exit code and output, recorded as a fact.

Open a project

Launch Anchor and point it at any git repository. On first open it reads:

• your git history (last 90 days), and

• Claude Code session transcripts for that folder, if you have any.

Click a file and you get every edit ever made to it, oldest to newest, each one showing the prompt that caused it. Where Anchor can prove the link from a recorded tool call it says so; where it only inferred it from timestamps, it says that too rather than pretending to be sure.

Connect it to Claude Code

Anchor's tools reach Claude Code over MCP. Claude Code starts the server itself, so Anchor does not need to be open for the tools to work.

Anchor is not added to your PATH. Typing anchor serve will not work — you need the full path to the binary. The easy way is to let Anchor write the line for you:

Settings → Claude Code connection → Copy

That gives you something like:

claude mcp add anchor -- "C:\Program Files\Anchor\anchor.exe" serve --project "C:\path\to\your\project"

Paste it into a terminal and run it. Then check it worked:

claude mcp list

You want to see anchor: ✔ Connected.

Once connected, Claude can call:

No tool merges, commits, pushes, deletes a branch, or writes to CLAUDE.md. Claude can recommend a winner; you merge it.

anchor_run_tests takes no command argument — it runs only the command you configured and confirmed, so a model cannot talk Anchor into running something else.

Run a split test

Using the full path again — substitute wherever your copy lives:

"C:\Program Files\Anchor\anchor.exe" split --prompt "freeze the streak when a day is missed" --n 3

That creates three branches, one worktree per lane, and prints the exact instruction to give Claude Code for each. Work them in any order — Anchor queues a test run when a commit lands on a lane, and opens Compare when all three have results.

Then, in chat: "use attempt 2" — Claude merges it with ordinary git. Nothing merges without you saying so.

Clean up the losers once you've decided:

"C:\Program Files\Anchor\anchor.exe" split --cleanup <task_id> --yes

What it writes

Only two things, ever: <project>/.anchor/ (its database and temporary worktrees), and a delimited block in CLAUDE.md that you approve by hand. It never edits your source files.

The CLAUDE.md block is a short list of what has already been tried and failed, so an agent is less likely to hand you the same wrong approach a fourth time. It is off by default, only ever written when you press the button, and only ever replaces the region between its own markers — everything you wrote by hand is preserved byte for byte.

To be precise about what that achieves: it is a text file the agent reads. It does not train or change the model, and it does not guarantee better output.

Build from source

Needs Node 18+, Rust (stable), a C toolchain (on Windows: Visual Studio Build Tools with "Desktop development with C++"), and git on your PATH.

git clone https://github.com/kimgeon555-lab/anchor.git
cd anchor
npm install
npm run app

The first build compiles a few hundred crates and takes several minutes. That gives you a development build that reloads as you edit.

To produce the installer yourself:

npm run app:build

The .msi lands in src-tauri/target/release/bundle/msi/, and a standalone anchor.exe in src-tauri/target/release/. Both the app and the CLI are that one binary.

Honest status

Version 0.1. It works, and it has been used on real projects — but it is new, and you should know its edges:

• Windows only, in practice. Built and tested on Windows 11. Nothing else has been packaged or verified.

• Not code-signed, so Windows will warn you on first run.

• Claude Code is the only agent whose transcripts are read today. Session sources sit behind one trait, so adding another is a single implementation.

• You need a real test suite. Anchor's whole premise is that your tests decide. Without them it can still record history, but it cannot pick a winner.

• Test worktrees don't have your dependencies. A fresh worktree has no node_modules and no virtualenv. Test commands that need an install step will fail environmentally — Anchor tells you when that's what happened rather than reporting it as a test failure.

• If Anchor can't parse your runner's output it reports counts unknown instead of inventing numbers.

Documentation

Full documentation is in docs/ — twelve pages covering the interface, the timeline, compare, the test runner, search, agent context, the data model, and troubleshooting.

Licence

MIT. See LICENSE.