SinghAbhinav04/Omni-Memory

SinghAbhinav04/Omni-Memory provides a persistent, branch-aware context layer for AI coding agents like Claude Code and Cursor. Instead of letting an agent lose track of decisions between sessions or hallucinate unverified architecture, it anchors stored facts directly to your git history and AST code graph.

Session memories get saved automatically when a session ends using deterministic hooks rather than relying on the agent to self-report. Retrieval runs through a local BM25F ranker, injecting relevant project facts into your prompts while flagging entries as stale if the underlying code changes. It also includes an offline local UI to inspect memory docs, project branches, and code dependencies.

For developers who want local, cross-session memory without setting up heavy vector databases or cloud dependencies, it is a practical tool.

Omni Memory tackles a common problem with coding agents: useful project knowledge is often lost between chats. The project stores decisions and technical facts locally, connects them to Git branches and code symbols, and brings relevant memories back into future prompts. It also checks whether saved information has become stale after the code changes. This is a thoughtful approach to reducing repeated explanations and incorrect assumptions.

The repository has a strong feature set for an early project. It includes a command-line tool, local dashboard, SQLite storage, branch tracking, code graphs, memory search, cleanup tools, export and import support, and integrations for several coding environments. The README does a good job of explaining the difference between building memory and connecting it to an editor. It also explains fallback behavior when tree-sitter is unavailable.

Testing is another positive area. The repository includes tests for storage, injection, graphs, cleanup, branch behavior, token use, evidence, and the local server. The latest GitHub Actions run is passing across the supported Python versions after recent fixes to tree-sitter parsing. The commit history shows active testing against real repositories and attention to token costs, stale memories, abandoned branches, and noisy captures.

Privacy and security should receive even more detail because OmniMemory reads source code, edits agent instruction files, installs hooks, and may process chat transcripts. The documentation should list exactly what is collected, where it is stored, which files are changed, and when information can leave the computer. Secret detection should run before any memory is saved or sent to a model. Users should also be able to preview every planned file change during setup and fully remove hooks and generated instructions with one command.

Stored memories should be treated as untrusted input. A bad or outdated memory could influence an agent in harmful ways, especially when it is inserted into every prompt. The project should test prompt injection, malicious repository text, database corruption, concurrent sessions, symbolic links, large repositories, and secrets hidden in generated files. Signed exports or checksums could help teams detect changes to shared memory files.

The proprietary license is clearly stated, which is helpful, but it may surprise visitors because the source is public on GitHub. A short plain-language section should explain what users may install, inspect, modify, or share. The README should also clarify the “zero dependency” wording because Python 3.10 and newer installations automatically include tree-sitter packages.

Overall, OmniMemory has a useful idea, strong local-first design, and an impressive amount of working functionality. Clearer privacy guarantees, stronger defenses against poisoned memory, and a tested compatibility table would make it much safer and easier to adopt.