memU Personal Memory
A shared, searchable memory layer that turns coding-agent session history into reusable Markdown skills.
Per-dimension scores and reasoning
Evidence shows: README describes installation and uninstallation, uninstall preserves memory store and config by default, requiring explicit user request to erase memory, indicating user confirmation and rollback awareness. However, no specific implementation details for least privilege, such as file system access scope or network permissions. Data flow transparency is good, README explains data flow (record, inject, commit, retrieve) and storage locations. Sensitive data handling: mentions API keys and config, but no encryption or protection measures. Dependency security: pyproject.toml lists dependency versions, but no vulnerability scanning or audit evidence. External effects: installation patches host instruction files, but no explicit user consent. Rollback: uninstall preserves data, but no version rollback mechanism. Source attribution: author and contact provided, but publisher unverified.
Evidence shows: README and pyproject.toml descriptions are consistent, test files exist, indicating some consistency. Dependency availability: dependencies and versions listed, but no lock file or mirror. Failure messages: tests have error matches, but no user-friendly error handling documentation.
Evidence shows: README lists multiple host agents and OS, scenarios clear. Capability boundaries: supported and unsupported agent modes are described. Trigger precision: retrieval and memorization trigger conditions described. Environment fit: supports multiple OS and Python versions.
Evidence shows: README structure clear, with quick start, configuration, host adapters sections. Install notes detailed, including pip, npx, uvx. Naming stable, version number present. Examples and FAQ: usage examples present, but no FAQ. Known limitations: some limitations mentioned in README. License Apache-2.0, but metadata NOASSERTION. Versioning changelog missing. Maintenance responsibility: author and contact provided, but no maintenance plan.
Evidence shows: Output usability: CLI commands and retrieval results provided. Marginal value: cross-agent memory feature, unique value. Cost benefit: claims free, unlimited, but no performance data.
Evidence shows: Some claims in README are supported by tests, but no traceable links. Cross-source corroboration: no external verification. Fact-inference separation: README distinguishes facts and inferences, but not clearly.
- Publisher identity unverified; review code before installation.
- Installation patches host instruction files, may affect agent behavior; proceed with caution.
- API keys and config storage lack encryption details, posing leakage risk.
- Dependency versions not locked, may introduce incompatibilities or vulnerabilities.
- Uninstall preserves data by default; explicit user request needed to erase, potential data residue.
What does this agent do, and when should you use it?
memU is a personal memory system that stores knowledge as a shared LLM wiki across sessions, agents, and devices. It runs as host-specific sidecars such as memu-codex, memu-claude-code, and memu-agent, mining local session histories. A scheduled bridge creates jobs from new sessions, while the host agent decides whether to create, update, or leave Markdown skills unchanged; MemoryService itself makes no LLM or chat calls. Submitted skills are embedded and stored on the skill track, then surfaced through progressive_retrieve for related future work. The shared backend can be local SQLite, Postgres, or memU Cloud.
Host adapters read known transcript sources, including ~/.codex/sessions/**/*.jsonl for Codex, project JSONL files for Claude Code, and read-only SQLite data for OpenClaw and Hermes. In the record path, prepare slices a session into self-contained self-evolve jobs containing context and file paths; the agent reviews related skills and either does nothing, patches an existing skill, or writes a new Markdown skill. commit sends disk changes through commit_results, after which MemoryService embeds the skill name and description and stores it on the skill track. The inject path patches a host instruction file so the agent runs <binary> retrieve before answering, returning relevant memory through progressive_retrieve. For unlisted hosts, memu-agent detect probes for recognizable JSONL logs and instruction files, while <binary> doctor checks configuration, selected mode, and a live retrieval.
- A Codex user who wants recurring project decisions and workflows from ~/.codex/sessions to inform later coding tasks.
- A developer alternating between Claude Code and Cursor who wants skills learned in one configured host to be retrieved by another.
- A privacy-conscious individual working on one machine who prefers a user-controlled SQLite or Postgres store over a cloud memory backend.
- An operator of OpenClaw, Hermes Agent, or WorkBuddy who wants to derive reusable skills from existing SQLite or JSONL session history.
- A user of an unsupported command-line agent who wants memu-agent detect to establish whether transcript capture and retrieval injection are possible.
What are this agent's strengths and limitations?
- It connects transcript capture, skill distillation, and future retrieval, with readable and editable Markdown skills as the durable output.
- Dedicated adapters cover Codex, Claude Code, Cursor, OpenClaw, Hermes Agent, WorkBuddy, and Cola, while memu-agent detect provides a documented path for other recognizable JSONL hosts.
- A single ~/.memu/config.env lets configured hosts share memory across tools, with SQLite, Postgres, and memU Cloud storage options.
- The memory service is limited to storing, embedding, and retrieving agent-prepared skills rather than independently making chat or LLM calls.
- Host integration requires access to local session logs and changes to host instruction files, which should be reviewed before adoption.
- Self-hosting still requires an embedding provider and API key; documented providers include OpenAI, Jina, Voyage, Doubao, and OpenRouter.
- Support varies by host and operating system: ChatGPT Chat and Claude Chat/Cowork are unsupported, and Linux Codex is listed as retrieval-only.
- SQLite uses brute-force cosine search and is intended for a single writer; concurrent or larger stores require Postgres, pgvector, and the optional postgres package.
How do you install or deploy this agent?
Python 3.11+ is documented. Install the CLI with pip install memu-cli; alternatives are npx memu-cli --help and uvx --from memu-cli memu. For Cloud mode, obtain an API key from memu.so and use the binary for the relevant host. For self-hosting, configure ~/.memu/config.env: host adapters require MEMU_DB, and the documented embedding settings are MEMU_EMBED_PROVIDER, MEMU_API_KEY, MEMU_EMBED_MODEL, plus optional MEMU_BASE_URL. Use MEMU_MEMORY_MODE to select Local or Cloud; an unset value remains Local for backward compatibility. After host setup, run <binary> doctor to verify the resolved configuration and retrieval path.
How do you use this agent?
After setup, the registered bridge captures new sessions and the patched host instruction file directs the agent to retrieve memory before it answers. A manual lookup is memu-codex retrieve "What should I remember about this project?"; use memu-claude-code, memu-cursor, memu-openclaw, memu-hermes, memu-workbuddy, or memu-agent for the corresponding host. For a host without a dedicated binary, run memu-agent detect first to see what transcript and instruction-file seams were found. Set MEMU_DB to a SQLite or Postgres DSN for local storage; Postgres requires pip install "memu-cli[postgres]".
How does this agent compare with similar options?
Unlike keeping context inside one assistant, memU shares learned session knowledge among configured hosts through one backend. Compared with memU Cloud, self-hosting stores memory in user-configured SQLite or Postgres, though it still requires an embedding provider.