# iMemory: A local control center for the long-term memory shared by coding agents

Side project · Public · Jordão Qualho, Senior Software Engineer

> A local dashboard for memory shared across coding agents. Search what they remember, inspect session handoffs and clean up context without touching the underlying database.

Technologies: JavaScript, HTML, CSS, MCP, REST

Code: https://github.com/jordaoqualho/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.

> **One source of truth.** The UI does not bypass the memory engine: reads use the public API, and writes follow the same MCP path used by agents.

## 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.

Built against ai-memory v2.4. The engine and its license (MIT) belong to akitaonrails/ai-memory.

---

Canonical: https://jordaoqualho.com/projects/imemory/ · Full profile: https://jordaoqualho.com/llms-full.txt · Contact: jordaoqualho@gmail.com