The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Kawa Code MCP listing page.
Team-aware memory for AI coding assistants. Track intent, record decisions, and see when a teammate is editing the same code — in real time, before commit.
@kawacode/mcp is the official Model Context Protocol (MCP) server for Kawa Code. It lets Claude Code, Cursor, and any MCP-compatible AI assistant:
gh) — enables richer data tiers (PR descriptions, review comments, issue discussions). Without gh, tiers 2 and 4 are skipped automaticallyAdd the MCP in your AI configuration, for example on Claude Code:
claude mcp add -s user kawa-intents -- npx -y @kawacode/mcp
For Cursor AI, install the MCP with npm install -g @kawacode/mcp and add it to ~/.cursor/mcp.json.
Note that the MCP will not be automatically updated to future versions in this scenario.
To upgrade to a newer release, run npm update -g @kawacode/mcp.
For the project you want Kawa Code to run on, create a .mcp.json file in your project root (recommended for teams — commit it to git):
The MCP server works together with the Kawa Code application, Kawa Code IDE extensions, and AI code generators such as Cursor AI and Claude Code.
Retired 2026-08-14. Do not wire this up. Kawa Code no longer installs it, and the setup wizard no longer asks for it.
This hook fired before every Edit/Write and surfaced prior reasoning attached to the file being changed. It was retired because its retrieval could not reach the decisions that mattered: it read only the most recently updated 100 decisions per repository, and architectural constraints — precisely what it existed to surface — are written once and then age out of a recency window permanently. On one of our own repositories, 160 decisions were of the surfaced types and only 17 were still inside that window.
If you already installed it, nothing breaks. The kawacode-on-pre-edit binary still ships, and an existing entry in your settings.json keeps working. Kawa Code will not remove it for you — delete it yourself if you want it off:
Nothing is lost on team coordination. The live collision signal moved to the Stop hook some time ago, and that is now the only edit-level coordination surface. It reports teammates whose in-progress, uncommitted edits overlap the lines you touched this turn — conflict detection before a merge conflict can exist. See Team conflict detection.
git log shows what changed; Kawa shows why.Kawa Code is built for more than one worker on a repository at a time — that's what the conflict detection is for. If those workers are AI agents you're running yourself, give each one its own git worktree. Agents sharing a single checkout overwrite each other's edits with no conflict marker and no git history: nothing is committed between the two writes, so nothing notices.
In Claude Code, background sessions already require a worktree — worktree.bgIsolation defaults to "worktree", which blocks edits to the main checkout until the session enters one. You only need to touch it if a project has explicitly opted out with "none". Subagents take isolation: "worktree" per spawn.
Two settings are worth tuning, because the defaults surprise people:
baseRef — defaults to "fresh", which branches from origin/<default-branch>. If you work on unpushed commits, set "head" to branch from your local HEAD instead. Either way this is a commit boundary: uncommitted working-tree changes don't travel into a new worktree, so land your work before spawning agents that need it.symlinkDirectories — nothing is symlinked unless you say so, so every worktree gets its own copy of whatever you leave out. Symlink dependency directories freely: node_modules is the same content for every worktree, and sharing it costs nothing. Do not symlink compiled-language build output — target/, build/, obj/. Those tools name artifacts deterministically from the crate/module and its inputs, without encoding which checkout they came from, so two worktrees building into one directory write the same filenames and silently overwrite each other. The symptom is the dangerous part: your suite goes green while running another checkout's binaries. Only a test that resolves a path baked in at compile time (Rust's env!("CARGO_MANIFEST_DIR"), include_str!, or an equivalent) will notice; everything else passes. If a suite ever looks suspiciously green after another checkout built in the same place, clean the build directory and re-run before believing it.Because compiled build directories can't be shared, they multiply — one per worktree, each growing independently, and they get large enough to matter (a mature Rust target/ reaches hundreds of gigabytes). Two things keep that affordable, and they solve different halves:
sccache is safe across worktrees precisely because it caches results keyed by input hash rather than sharing an output directory.cargo-sweep removes stale artifacts by age or to a size cap; wire it into whatever cadence fits your setup — after merging a worktree back is a natural trigger. One caveat worth knowing before you rely on it: sweeping only reclaims artifacts the build tool still tracks. If that index has been lost, the leftovers are orphaned and a sweep reports nothing to do no matter the flags — a full clean is the only thing that reclaims them.Isolation alone would just give you several agents doing overlapping work in private. Kawa's job is the coordination on top.
Each agent session gets its own identity, and intents are tracked per session — so several intents can be active on one repository at once, each with its own current focus, without a lock and without agents clobbering each other's context. From there the normal machinery applies across agents exactly as it does across teammates: get_relevant_context surfaces what the other agents have already decided, create_and_activate_intent reports a conflict when new work overlaps something already in flight, and the pre-edit check fires on reasoning any of them recorded.
The practical result: your agents inherit each other's decisions instead of re-deriving them, and you find out about overlapping work while it's still cheap to redirect — not at merge time.
Kawa can do more than report an overlap — arbiter_resolve judges each one, and arbiter_apply will write the safe tier of merge for you. That write is deliberately gated:
arbiter_applywrites only in an agent-owned worktree. On a human checkout — or when a peer holds the file-set lock — it stays suggest-only.
This is the sharpest practical reason to put agents in worktrees. Run them on a shared checkout and auto-resolution silently never engages; you get the conflict surfaced and nothing else, with no error to tell you a capability was switched off. The guardrail is intentional — Kawa won't rewrite a human's working tree underneath them — but it does mean the setup decides whether half the feature is available.
Because the reasoning behind your work — your intents and recorded decisions — lives in Kawa Code rather than in the chat log, a teammate can pick up where you left off from a single prompt. No transcript sharing, no session restore.
check_active_intent, or you can find it in the Kawa Code app.Follow up on intent <intent-id>: <what's left to do>.resume_intent(<id>) — one call that adopts the intent as their current focus and loads its recorded decisions — resuming the thread with full context, even though it never saw your chat.What transfers: the intent, its decisions, and (once committed) its code. What doesn't: your chat transcript and any session-local state. An acknowledgment you made to a pre-edit block is your judgment in your session, so your teammate re-evaluates it rather than inheriting it — which is what you want.
Teams: to make the handoff seamless, add one line to your shared CLAUDE.md so the agent always treats a follow-up prompt as resuming the named intent instead of opening a new one:
When a prompt says "follow up on intent
<id>" (or similar), callresume_intent(<id>)to adopt that intent and load its decisions — do not create a new intent for it.
When you port a codebase to a new language or rebuild it in a fresh repository, the code moves — but the reasoning usually doesn't. The source repo's decision history knows why retired approaches were retired, which constraints are load-bearing, and where the security landmines are. With Kawa Code, that history becomes a first-class migration input.
Decisions are scoped per repository, so the new repo won't surface the old repo's history automatically. Transplant them slice by slice as you port — this is the recall-transplant workflow:
get_relevant_context against the source repo with a description of the subsystem you're about to port (name its key files). This surfaces the forks, constraints, trade-offs, and discoveries that shaped it.get_decision_detail on the load-bearing hits for the full rationale and consequences.record_decision, citing provenance in the summary or rationale (e.g. [transplanted from <source-repo> <decision-id>]). Merge decisions that form one lineage into a single record.The payoff compounds: the port doesn't re-litigate settled arguments or faithfully reproduce old bugs, negative knowledge survives even though the code that motivated it was deleted long ago, and at cutover the new repo starts with a curated decision corpus instead of an empty one.
The CLAUDE.md template ships a compact version of this workflow, so agents set up through the Kawa Code welcome flow follow it automatically.
Most Kawa tools run every turn — check the active intent, recall context, record a decision. The operations below are different: you run them rarely, sometimes once per repository. They cost real time and money, and they are not part of the per-turn loop.
infer_historyA brand-new Kawa repo knows nothing about work that predates it. infer_history mines the existing commit history into intents and decisions, so recall has something to draw on from day one. Run it once when you connect a repo with meaningful history; after that it extends incrementally.
It is agent-invoked — ask your assistant, e.g. "Run infer_history with max 3000 commits". There is no button for it in the Kawa Code app.
Always estimate first. The tool defaults to estimateOnly: true, which returns a token/cost preview without running anything. Look at the number, then re-run with estimateOnly: false to actually start. A run is asynchronous — it returns immediately and reports progress in the Kawa Code app — and resumes from where it stopped if interrupted.
| Parameter | Default | Purpose |
|---|---|---|
estimateOnly | true | Preview cost without running. Set false to execute. |
commits | resume | How many recent commits to analyze. Omit to continue from the last run. |
commitRange | — | Git revspec (sha1..sha2, branch1..branch2, sha1^!) for a specific window. Mutually exclusive with commits. Good for backfilling a PR or recovering a dropped batch. |
contextIssues | false | Pull in PR/MR descriptions and issue discussions. Needs an authenticated gh or glab; silently skipped otherwise. |
allowCommitSplitting | false | Enable when one commit often mixes unrelated changes. |
maxStories | — | Per-run cap on stories analyzed. |
model | — | Affects the estimate only. The run's model is configured in the Kawa Code app. |
force | false | Override the re-run guard — see below. |
The re-run guard. If the repo already has intents and the run can't cleanly resume (missing or unreachable cursor), or HEAD isn't on the default branch, the call stops and returns needsDecision instead of running. That's deliberate: re-running blind duplicates intents. Read the reason, and only pass force: true if it genuinely applies. Prefer running on main/master; force exists for the deliberate feature-branch case.
GitHub and GitLab are both supported; the forge is detected from the remote origin.
Curating decisions into an evolution graph is phase 5 of infer_history, run automatically once the analysis completes. There is no separate step and nothing to invoke.
Earlier versions exposed an
evolve_decisionstool. It has been removed: it required astoriesarray that only ever existed inside the pipeline's own memory, so no assistant could construct a valid call. Nothing is lost — the curation still runs, as part ofinfer_history.
Features group a repo's intents into a browsable catalog. Rebuild it from the Features panel in the Kawa Code app:
Progress shows in the app, and the catalog also extends automatically after an infer_history run.
Earlier versions exposed an
update_featuresMCP tool that sent the same request as the Update features button. It has been removed — one button and one tool doing the identical thing meant every session paid for a tool schema it never needed. Press the button instead.
To test the MCP server without integrating it into an AI assistant:
npm run buildnpm startnpm run dev to auto-rebuild during developmentContributions are welcome. Please read CONTRIBUTING.md and CLA.md.
This project is source-available under the Kawa Code Source Available License.
You may run and modify the software for personal or internal use.
See LICENSE for details.