Edda

Automatic decision memory for Claude Code with cross-session persistence.
Local, deterministic, and zero API cost — no LLM, no embeddings, no cloud.

What is Edda? · Install · Quick Start · How It Works · Comparison · Integration · Architecture

English · 繁體中文

What is Edda?

Claude Code can compact context within a session, but important decisions can still get buried in noise, and that context does not persist across sessions by default.

Edda takes a different approach: instead of compressing everything, it extracts key decisions and their rationale, stores them in a local decision ledger, and makes them available to future sessions.

When a new session starts, the agent can retrieve relevant past decisions, understand what was decided and why, and continue work with better continuity.

Edda also works with OpenClaw and any MCP client.

You don't need to do anything. After edda init, hooks handle everything:

Session 1                          Session 2
  Agent decides "db=SQLite"          Agent starts
  Agent decides "cache=Redis"   →    Edda injects context automatically
  Session ends                       Agent sees: db=SQLite, cache=Redis
  Edda digests transcript            Agent continues where it left off

Everything stays local — data lives in .edda/ (SQLite + local files), with no cloud, no accounts, and no API calls.

Install

# One-line install (Linux / macOS)
curl -sSf https://raw.githubusercontent.com/fagemx/edda/main/install.sh | sh

# macOS / Linux (Homebrew)
brew install fagemx/tap/edda

# crates.io
cargo install edda

# Or download a prebuilt binary
# → https://github.com/fagemx/edda/releases

Quick Start

edda init    # auto-detects Claude Code, installs hooks
# Done. Start coding. Edda works in the background.

edda init does three things:

1. Creates .edda/ with an empty ledger
2. Installs lifecycle hooks into .claude/settings.local.json
3. Adds decision-tracking instructions to .claude/CLAUDE.md

The CLAUDE.md section teaches your agent when and how to record decisions:

## Decision Tracking (edda)

When you make an architectural decision, record it:
  edda decide "domain.aspect=value" --reason "why"

Before ending a session, summarize what you did:
  edda note "completed X; decided Y; next: Z" --tag session

This is the key to Edda's automation — the agent learns to call edda decide naturally during conversation, and hooks capture everything else.

How It Works

Claude Code session
        │
   Bridge hooks (automatic)
        │
        ▼
   ┌─────────┐
   │  .edda/  │  ← append-only SQLite ledger
   │  ledger  │  ← hash-chained events
   └─────────┘
        │
   Context injection (next session)
        │
        ▼
   Agent sees all prior decisions

Edda stores every event as a hash-chained JSON record in a local SQLite database. Events include decisions, notes, session digests, and command outputs. The hash chain makes the history tamper-evident.

At the start of each session, Edda assembles a context snapshot from the ledger and injects it — the agent sees recent decisions, active tasks, and relevant history without reading through old transcripts.

How Edda Compares

Every query runs locally against SQLite — same answer every time, in milliseconds, at zero cost.

Integration

Claude Code — fully supported via bridge hooks. Auto-captures decisions, digests sessions, injects context.

edda init    # detects Claude Code, installs hooks automatically

OpenClaw — supported via bridge plugin.

edda bridge openclaw install    # installs global plugin

Any MCP client (Cursor, Windsurf, etc.) — 7 tools via MCP server:

edda mcp serve    # stdio JSON-RPC 2.0
# Tools: edda_status, edda_note, edda_decide, edda_ask, edda_log, edda_context, edda_draft_inbox

Manual Tools

Most of the time, hooks handle everything automatically. These commands are available when you want to record something manually or look something up:

edda ask "cache"           # query past decisions
edda search query "auth"   # full-text search across transcripts
edda context               # see what the agent sees at session start
edda log --type decision   # filter the event log
edda watch                 # real-time TUI: peers, events, decisions

Architecture

14 Rust crates:

.edda/
├── ledger.db             # SQLite: events, HEAD, branches (append-only, hash-chained)
├── ledger/
│   └── blobs/            # large payloads
├── branches/             # branch metadata
├── drafts/               # pending proposals
├── patterns/             # classification patterns
├── actors.yaml           # roles (lead, reviewer)
├── policy.yaml           # approval rules
└── config.json           # workspace config

{
  "event_id": "evt_01khj03c1bteqm3ffrv57adtmt",
  "ts": "2026-02-16T01:12:38.187Z",
  "type": "note",
  "branch": "main",
  "parent_hash": "217456ef...",
  "hash": "2dfe06e7...",
  "payload": {
    "role": "user",
    "tags": [],
    "text": "Phase 0 complete: edda in PATH, hooks installed"
  },
  "refs": {}
}

Roadmap

• Prebuilt binaries (macOS, Linux, Windows)
• One-line install script (curl | sh)
• Homebrew tap (brew install fagemx/tap/edda)
• Decision recall metrics
• Cross-project decision search
• tmux-based multi-pane TUI (L3)

Contributing

Contributions welcome. See CONTRIBUTING.md for development setup.

Community

• GitHub Issues — bugs & feature requests
• Releases — changelog & binaries

License

MIT OR Apache-2.0

Your agent's architecture decisions shouldn't reset every session.