正在載入留言。
正在確認登入狀態。
持久內存供 Claude Code 和 Codex CLI 使用,永不提供已替換的決策,並將 CLAUDE.md / AGENTS.md 規則轉換為權限規則與拒絕掛鉤。本地優先:單一 Rust 二進位檔案,SQLite + FTS5,無雲端、無 API 金鑰、讀取路徑中不使用 LLM。提示錨定回憶受 700 令牌預算限制。
AI 翻譯
Persistent memory for Claude Code and Codex CLI that never serves a replaced decision, and turns CLAUDE.md / AGENTS.md rules into permission rules and deny hooks. Local-first: one Rust binary, SQLite + FTS5, no cloud, no API key, no LLM in the read path. Cue-anchored recall under a 700-token budget.
取自儲存庫 README
正在載入完整 README。 以下為已儲存的摘錄。
Muninn: persistent memory for Claude Code and Codex
A memory for Claude Code and Codex that keeps up when you change your mind.
Every time you open a new session, Claude Code or Codex starts from zero, with no idea that last
week you picked a database, agreed on a folder structure, or told it never to touch a certain
file. So you explain it all again, or it guesses.檢視完整 README ↗A memory for Claude Code and Codex that keeps up when you change your mind.
Every time you open a new session, Claude Code or Codex starts from zero, with no idea that last week you picked a database, agreed on a folder structure, or told it never to touch a certain file. So you explain it all again, or it guesses.
Memory tools fix the forgetting, but most of them bring a new problem. They remember everything, including the decisions you have since changed. Ask about the database and the assistant gets the old choice and the new one side by side, and has to guess which is current. Sometimes it guesses wrong, and you find the old choice back in your code.
Muninn remembers what you decided, and when you change your mind, it puts the old decision away. The assistant only sees what is true now. The old one is still in your history if you ever want to look.
It also turns the rules in your CLAUDE.md or AGENTS.md into settings that block the action,
so "never edit the migrations folder" holds even when the assistant has forgotten it. It runs on
your computer, with no cloud service and no API key.
On Monday you tell the assistant:
Let's use gzip to compress the files we send.
On Thursday you change your mind:
Change of plan, let's use zstd instead.
Two weeks later, in a brand-new session, you ask it to write up how the project compresses files. The assistant remembers neither conversation, so it checks its memory. A typical memory tool hands it both messages. Muninn hands it only Thursday's, and the assistant writes zstd.
We tested it against two popular memory tools, claude-mem and agentmemory. Every tool got the same conversations, and the assistant was then given tasks that depended on a decision that had later been changed.
An early measurement also points to lower costs: on those same tasks the assistant took about half as many steps with Muninn, and each task cost about 40% less. That figure has not been confirmed by a test of its own yet, so read it as a first sign.
Each test had its rules written down before it ran, and all the raw results are in this repository, so anyone can check them. The full comparison, including the tools we have not tested yet, is in docs/why-muninn.md.
You never call Muninn. It rides along on the hooks Claude Code and Codex already fire, reads from a small database in your project, and writes to it only when a session ends.
Once it is set up it works in the background, and you keep talking to your assistant as usual. It keeps what you actually said rather than a summary of it, so nothing gets rewritten into something you never meant. Everything stays on your computer: Muninn has no account and no cloud service, and it never sends your conversations anywhere. It adds a few thousandths of a second to each message.
Claude Code reads CLAUDE.md as context, and a rule in it can be lost when a long conversation
is compacted or simply not followed. Muninn turns a rule such as "never edit the migrations
folder" from CLAUDE.md, AGENTS.md or .claude/rules into Claude Code permission rules and a
deny hook, so the edit is refused before it happens. It shows you the proposed settings first
and changes nothing until you say yes:
muninn compile && muninn apply
In Claude Code, /muninn:apply does the same.
Every row below comes from the same test harness: the same live sessions filled each tool's memory through its own hooks, and a fixed check graded what the assistant wrote. No AI judge graded anything.
| Muninn | claude-mem | agentmemory | |
|---|---|---|---|
| Uses the current decision after you changed it in conversation | 252 / 270 | 208 / 268 | not in this run |
| …when the change also reached the code | 54 / 54 | 25 / 54 | 1 / 54 |
| Writes a replaced value into its work anyway | 0 / 54 | 10 / 54 | — |
| Same conversations give the same memory | yes, 3 runs of 20 sessions stored the same records | stored text did not overlap between two runs | not measured |
| Room it takes in the assistant's context | about 2.4 times claude-mem's | baseline | not measured |
Every row above measures the same case: a decision that changed while the project went on. If you need one memory for a whole team, use an assistant other than Claude Code or Codex, or already run short on context, read the limits below before you install. Mem0, Zep, Letta and Claude Code's built-in memory have not been run on the same harness, so there is no figure to compare. docs/why-muninn.md says why for each one.
git push does not share it with anyone. Muninn keeps its folder out of
your repository, so your conversations are not published along with your code.You need Claude Code or Codex. You do not need to know how to program. Installing is done once per computer; after that, you turn Muninn on in each project where you want memory.
It works on Windows, macOS (Apple silicon and Intel) and Linux. On Windows, Claude Code needs Git for Windows installed, the same thing Claude Code itself asks for; Codex needs nothing extra.
Type these two lines in Claude Code, one at a time:
/plugin marketplace add ilien-dev/muninn
/plugin install muninn@muninn
Restart Claude Code. The first session downloads Muninn itself, about 13 MB, and checks the download before using it.
Run these in a terminal:
codex plugin marketplace add ilien-dev/muninn
codex plugin add muninn@muninn
Open Codex, type /hooks and approve Muninn's hooks. Codex runs no plugin hook until you do.
The first session after that downloads Muninn, the same way as in Claude Code.
Muninn stays silent in a project until you turn it on there. Do it once per project, on each computer you work from: the memory lives on your machine, not in the repository, so a fresh clone starts without it.
In Claude Code, open the project and type:
/muninn:init
In Codex there is no command for this, so you ask Codex to do it. Open Codex in the project folder, paste this message and send it:
Run `muninn init` in this project, then `muninn status`. If `muninn` is not found, use `~/.local/bin/muninn` instead (on Windows, `~/.local/bin/muninn.exe`). Show me what both commands print.
Codex may ask your permission before running them; say yes. When it's done, the last line it
shows starts with MUNINN and says GREEN.
If you prefer the terminal, run this inside the project folder instead:
~/.local/bin/muninn init
On Windows, in PowerShell: ~\.local\bin\muninn.exe init.
That file appears after your first Codex session with the plugin installed. If it isn't there yet, open Codex once, close it, and try again.
To check it in Claude Code, type /muninn:status: it prints a line starting with MUNINN that
says GREEN. Memory starts filling from that conversation on. If you use both assistants on the
same project, one init covers both.
What init changes in the project:
.muninn/ folder, where the memory is kept, and adds it to .gitignore, so
your conversations never end up in a commit.muninn init --keep-native leaves it
on.muninn why, muninn status and muninn show without asking you
each time.Running it twice is harmless. To remove Muninn from a project, run muninn clean --yes: it
undoes exactly what init changed.
/plugin, choose the muninn marketplace and update it, or turn on
auto-update there once.codex plugin marketplace upgrade.Restart the assistant afterwards. You don't run muninn init again: the first session after an
update fetches the new version, and the memory you already have stays.
You don't need to do anything. Muninn listens while you work. If you are curious, you can ask it what it knows:
muninn why "why did we pick zstd" # what stands now, and what it replaced
muninn status # is everything healthy
Each session starts with an empty context: the assistant only knows what is in CLAUDE.md and
what you tell it again. Muninn keeps the decisions, rules, corrections and dead ends from earlier
sessions and hands the ones that matter back to the assistant when you write a message, capped at
700 tokens. Codex works the same way, and Muninn covers it with the same memory.
CLAUDE.md is read as context, not as a setting, so a rule can be dropped when the conversation
is compacted or skipped during a long task. Muninn helps in two ways. Rules come back from its
store after a compaction, not from the summary (100 of 100 times in our test). And a rule you
turn into a setting with muninn compile && muninn apply blocks the action whether or not the
assistant remembers it.
No. There is no account, no server and no cloud service. The memory is a folder called
.muninn/ inside your project, and init adds it to .gitignore so it never reaches a commit.
On the first session the plugin downloads Muninn itself and checks it against its checksum
before it runs.
Not noticeably. The hooks are held to hard limits in CI with a full store of 20 000 records: 2.8 ms for a session start and 4.0 ms for a message (95th percentile). No AI model runs while it answers the assistant.
Your session carries on. Every hook exits cleanly even when something inside it fails, and the
error goes to a log in .muninn/log/. A test drives the real hooks 200 times per run, including
with the database corrupted, and fails if a hook blocks or a retired decision leaks out.
muninn status tells you what is wrong.
No key and no running cost. Muninn is a single program on your computer, and it does not call a paid model.
init turns Claude Code's built-in memory off for that project. If you want to keep both, run
muninn init --keep-native.
It does the same job as claude-mem: memory across sessions, through hooks, for coding assistants. The difference is what happens when a decision changes. We tested Muninn against claude-mem and agentmemory on that case, and the results are above. Mem0 and engram have not been run on the same test, so there is no figure to compare yet.
Not yet. Each person's memory is built from their own conversations and stays on their machine.
A git push does not share it.
muninn why "your question" shows what stands now and what it replaced, and
muninn why --all "topic" includes the retired ones. To remove Muninn from a project, run
muninn clean --yes, which undoes exactly what init changed.
In Norse myth, the god Odin keeps two ravens. Every morning they fly out over the world, and every evening they come back to tell him what they saw. Huginn is thought; Muninn is memory. In one of the old poems, Odin says he worries that Huginn may not come back, and that he worries more for Muninn.
That always struck me as the right way round: a thought can be had again, and a memory that does not come back is gone.
Your AI assistant is Huginn. It thinks fast, it covers a lot of ground, and every morning it starts from nothing. Muninn is the one that comes back carrying what you decided.
Muninn is © 2026 ilien and free to use under the
GNU Affero General Public License, version 3 only, with the extra terms in
NOTICE. In short:
Want to contribute? There is a one-time Contributor License Agreement; see CONTRIBUTING.md.
The animations in this README are drawn from assets/motion/source/
and can be rebuilt with node export.mjs there.