notnessie

NotNessie

A Claude Code-native, local-first project memory layer.

NotNessie captures the decisions, constraints, preferences, verified commands, bug notes, and task summaries that come out of your Claude Code sessions, then serves them back to Claude Code as compact context — so the assistant gets better over time inside a repository instead of starting every task from zero.

Local-first. No account, no cloud. Your memory lives in your own Postgres, on your own machine. There is no sign-up, no sync service, and no telemetry.

Get started → · How it works

The problem

Every new Claude Code task tends to need the same context re-explained:

Use Fastify, not Express.
Use PostgreSQL.
Do not edit generated files.
Run tests with pnpm test.
The project uses pnpm, not npm.
Do not change the public API response format.

That knowledge is real and durable, but it evaporates between sessions. The assistant re-learns your project on every conversation, and you re-type the same corrections. NotNessie turns those corrections into structured project memory and replays it at the right moment.

How it works at a glance

NotNessie wires into Claude Code three ways, all set up for you by notnessie init:

1. An MCP server (.mcp.json) exposing nine memory tools — for retrieving context and saving decisions, constraints, preferences, verified commands, and task summaries. See MCP tools.
2. Five lifecycle hooks (.claude/settings.json) — SessionStart injects a context pack, Stop and PreCompact summarize the session into memory, and UserPromptSubmit / PostToolUse capture context along the way. See Lifecycle hooks.
3. A CLAUDE.md instruction block and a skill that tell Claude when to retrieve memory and when to save it.

Underneath, memory is stored in PostgreSQL with the pgvector extension. Retrieval is hybrid — Postgres full-text keyword search plus local semantic embeddings — re-ranked by recency, confidence, type, pinned status, and mentioned files. Embeddings run locally via Transformers.js; when they are disabled or unavailable, search degrades cleanly to keyword-only.

SessionStart hook ──► context pack injected into Claude Code
        │
        ▼
You work with Claude Code ──► it saves decisions / constraints / commands
        │
        ▼
Stop & PreCompact hooks ──► session summarized into memory
        │
        ▼
Next session ──► richer context pack, automatically

What gets remembered

NotNessie stores ten kinds of memory: project facts, decisions, preferences, constraints, verified commands, task summaries, bug notes, failed attempts, TODOs, and open questions. Read about each on the Concepts page.

A core principle: current code wins over memory. Memory is background, not gospel. When a stored note conflicts with the codebase, Claude is told to follow the code and flag the stale note.

Curate what was captured

Automatically captured memory is never perfect, so NotNessie ships a local dashboard (notnessie dev) for reviewing, editing, pinning, and deleting memories — a ledger you scan and correct. Provenance and confidence are first-class, because you are curating machine-written notes.

Privacy by default

NotNessie refuses to store private keys, credential-bearing connection strings, and .env dumps, and redacts JWTs, API keys, and bearer tokens inline before anything is written. It never stores full transcripts or raw terminal output. See Configuration and the Architecture page.

Next steps

• Installation — prerequisites, install, and first run.
• Quick start — use it with Claude Code, or standalone.
• Concepts — memory types and how memory flows.
• About & credits — the Nessie homage and the honest “vibe-coded” note.

This site is open source. Improve this page.