iMemory.

Overview

iMemory is a web interface for ai-memory, Fabio Akita's open-source MCP server for persistent, local memory across coding agents. Instead of giving each agent an isolated context, ai-memory lets Claude Code and other MCP-compatible agents reuse the same memories, session handoffs and project knowledge on your own machine. iMemory turns that engine into a practical dashboard: one place to inspect what agents remember, search across projects, review past sessions and manage the memory they share. It does not fork or replace ai-memory. The server remains the source of truth and mounts iMemory as its web interface through --web-ui-dir.

What it does

• Shows projects, recent memories and search in one overview.
• Lets you inspect the memories associated with each project.
• Makes agent sessions and handoffs visible instead of leaving them hidden in tooling.
• Provides cleanup with a preview before changes are applied.
• Supports deletion with undo.
• Lets you explicitly save the current session when you want an agent's context preserved.

Why I built it

When I started using multiple coding agents, the main problem was not generating code. It was keeping context consistent between them. A decision made in one session could be missing from the next tool, and reconstructing it wastes time and tokens and makes handoffs less reliable.

ai-memory solves storage and retrieval. I built iMemory to make that shared memory observable and manageable: to see what is being remembered, which sessions created it, and to clean it up without working directly with internal files or databases.

How it’s built

The interface stays deliberately thin.

• Reads use ai-memory's public REST API under /api/v1.
• Mutating operations use the same MCP tools exposed to coding agents, instead of adding a private write path.
• The UI is plain HTML, CSS and JavaScript with no frontend build step.
• The ai-memory server serves the interface itself through --web-ui-dir.
• The repository can also act as the local ai-memory data directory.

That last part meant treating local data as sensitive by default. A deny-by-default .gitignore lets only the interface, documentation and public assets into Git, while the memory database, wiki, configuration, logs, backups and local project data stay on the machine.

Design decision

iMemory is intentionally not a fork. The server, hooks, memory engine and MCP implementation continue to come from akitaonrails/ai-memory. That keeps the project small and lets the interface evolve without duplicating the underlying memory system.