MemoryWhale CLI
Local debugging memory for developers and agents: commands, output, errors and working fixes stored in local SQLite
- 145 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- Typed commands and their output land in the local store, so passwords and keys may end up there
- Recording is switched on globally and affects every terminal session until it is turned off
Install
- Works in
Manual install
brew tap wuisabel-gif/memorywhale https://github.com/wuisabel-gif/MemWhale && brew install memorywhaleCommand from the README. `cargo install memorywhale-cli` and an install script with a checksum check also work. Then `mw --version` and `mw doctor`.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- Typed commands and their output land in the local store, so passwords and keys may end up there
- Recording is switched on globally and affects every terminal session until it is turned off
This is third-party code. Review the repository files before installing.
What it does
MemoryWhale records what actually happens while you debug: commands, output, failures and the fixes that worked. Everything is stored in local SQLite, so you can find it after the terminal, SSH connection or agent session is gone. When you hit an error again, MemoryWhale reminds you that you have seen it and hands back the fix. It works with nineteen coding agents through MCP, with no account and no upload. The command is `mw`: `mw global on` turns recording on and `mw doctor` checks the setup. There is a web UI and a menu bar desktop app that shows what the agents were told, the commands and output behind it and the lessons accumulated. The authors give measurements: on LongMemEval search puts a session holding the answer in the top five for 97% of 470 questions, and on synthetic project bug tasks an agent solved 25% without memory and 96% with it. They note this demonstrates the mechanism and is not a field study.
Who it is for. Developers who often solve the same errors again and users of coding agents who want shared debugging memory across sessions.
Good fit when
- An error repeats and the past fix vanished with the terminal
- Several coding agents should see a shared debugging history
- You want to search commands, output and failures from an SSH server
- Memory must stay on the machine with no account
Not a fit when
- You need shared team memory in the cloud: data is stored only locally
- You need to run on Windows without WSL: the README advises WSL
- Recorded commands and output contain secrets that must not be kept on disk
Example request
Search the debugging memory for how I fixed the database connection error last week and show the commands that helpedLimitations
Prebuilt binaries exist for Linux (x86_64 and aarch64) and macOS, and Windows users are advised to run MemoryWhale in WSL. The README offers an install script with a checksum check, `cargo install memorywhale-cli` and Homebrew. Recorded commands and output go into a local database where secrets may land, so restrict access to it. Quality figures come from a public benchmark and synthetic tasks. The last commit is dated November 8, 2026, and the store schema migrates on upgrade.
How to disable. Run `mw global off`, disable the MemoryWhale MCP entry in agent settings and uninstall the program (`brew uninstall memorywhale` or `cargo uninstall memorywhale-cli`), then delete the local SQLite store.
FAQ
Where does MemoryWhale store data?
In local SQLite. No account is needed and nothing is uploaded.
Which agents does it work with?
With nineteen coding agents through MCP, as stated in the README.
How do I turn recording on?
With `mw global on`, and `mw doctor` checks the setup.
Is there a windowed version?
Yes, a desktop app lives in the menu bar and shows notes, commands and accumulated lessons. It ships with releases from 0.23.
How reliable are the README figures?
They are measurements on the public LongMemEval benchmark and synthetic tasks, and the authors call them a demonstration of the mechanism and not a field study.
Discussion
No questions or reviews yet.
Related
CLI toolsA persistent-memory MCP server for coding agents: a graph of a project's concepts, architecture and decisions that survives across sessions
An MCP layer of persistent collective memory for agents: structured storage, semantic search, a relation graph and a supersession lineage
Local shared project memory for coding agents: facts, decisions and commits available through MCP, CLI and hooks in any agent
A local code graph with version history: an MCP server that tells the agent who calls a function and what an edit breaks
A local CLI stores project decisions and conventions in SQLite, retrieves relevant entries and shares memory across coding agents.
A plugin saves coding-agent observations in local memory and retrieves history through search, timelines and MCP tools.
Comparison with similar tools
Cards that share the main search query, and how they differ.
| Tool | Official | Authentication | Repository stars | Main difference |
|---|---|---|---|---|
| MemoryWhale (this card) | no | 145 | ||
| Claude-Mem | no | 116,457 | keeps debugging commands, output and fixes locally for nineteen agents | |
| agentmemory | yes | not required | 30,314 | memory of debugging specifically: errors, commands and working fixes |
README in short
The README presents MemoryWhale as persistent local debugging memory for developers and agents. It gives benchmark figures, version 0.26.0 with release notes, installation by script, Cargo and Homebrew, a sixty-second example and an invitation to contribute. README translations exist in several languages.