One SQLite file can serve several coding agents
Engram stores observations, session summaries, prompts, and project context in SQLite with FTS5 search. The same binary exposes 20 MCP tools for saving, updating, searching, comparing, reviewing, and inspecting memory. Claude Code, Codex, Gemini CLI, OpenCode, Cursor, VS Code, and other clients can point at that store rather than keeping separate notes. This is useful for developers who change tools but want architectural decisions and debugging history to survive the switch.
The design stays understandable. An agent calls a save tool after meaningful work, Engram indexes the record, and a later session searches by project or topic. The terminal UI lets a human browse and edit the store. Local data remains authoritative even when cloud replication is enabled. This is preferable to hiding memory in an opaque hosted agent account, though the quality of recall still depends on what the agent saves and how it searches.
Stdio MCP keeps local setup simple and remote access awkward
For most supported clients, engram setup writes configuration and the client launches engram mcp as a short-lived stdio process. There is no daemon to expose for basic use. The binary and SQLite file can remain on the developer's machine, and the MIT license permits inspection and modification. The README also documents Homebrew plus Windows and Linux installation paths.
The same transport choice limits remote use. Engram has no network MCP endpoint. Its HTTP API is a separate interface used by some plugins, and engram serve binds to 127.0.0.1 with no supported bind-address flag. A Dockerized agent cannot reach the host loopback directly. The documented workaround is to mount the Engram binary into the container, launch MCP there, and share ENGRAM_DATA_DIR through a volume. That is workable for one host, less convenient for a remote agent fleet.
What happened when we ran it
Our sandbox cloned commit 47f281c and installed 97 Go packages in 27 seconds. The 51.4 MB checkout contained 500 files and about 121,062 lines of source. The build completed successfully in 40 seconds. Engram had 6 CI workflow files and no Dockerfile or top-level tests directory, although Go tests live alongside the packages they cover.
The test run ended with exit code 1 after 476 seconds. Our harness counted 20 passed and 2 failed out of 22. internal/store failed after 360.213 seconds, but the supplied tail does not include its assertion or error. TestCodexUnixSessionEndAdapter failed immediately with the explicit message that Unix SessionEnd runtime tests require jq and curl. The internal/sync, internal/timeutil, internal/tui, and internal/version packages shown in the tail passed.
This result should not be flattened into one missing-package explanation. The plugin failure names two absent command-line tools; the store failure remains unexplained by the evidence we have. A buyer should run the suite on the target operating system with documented test prerequisites, then investigate internal/store independently if it repeats. Our run did not connect an actual coding agent or evaluate retrieval relevance.
Memory still depends on agent behavior
The README is candid that setup wiring alone may not make an agent remember consistently after long sessions or context compaction. It provides an optional memory-protocol snippet for persistent prompt files when the client stops calling Engram reliably. That is the central product tradeoff: Engram can store and retrieve facts, but the agent chooses when a decision is worth saving and when previous context should be searched.
Teams should define a small policy before filling the database. Save decisions, failed approaches, exact commands that matter, and project conventions. Avoid copying secrets, transient logs, or every chat turn. Test recall with questions people actually ask after a week away. FTS5 defaults to requiring all query tokens, while match_mode: any broadens recall when the exact phrasing is forgotten. Human review through the TUI remains useful for deleting noise and correcting stale notes.
Cloud replication adds identity and repair operations
Git sync exports compressed chunks for sharing across machines, with local SQLite still treated as the source. Engram Cloud goes further with project-scoped replication, enrollment, managed tokens, allowlists, a dashboard, and explicit doctor, repair, bootstrap, and status commands. The README blocks an all-project cloud sync by design. These controls are welcome, but they turn a local memory helper into a service that needs database backups, secrets, upgrade rehearsal, and access review.
Open issue #597 reports that cloud bootstrap admin --issue-token on v1.19.0 could create the administrator and grant, then reject its own audit metadata and leave no managed token. Version 1.20.0 is newer, yet the issue was still open when researched. Verify first-admin creation on an empty disposable database, store the one-time token safely, and prove the recovery path before moving existing memories.
Claude Code and Codex integrations need client-specific checks
Engram provides a Claude Code plugin and setup paths for many agents, but client contracts differ. Issue #700 reports that server instructions exceeded Claude Code's 2,048-rune limit on a measured commit, causing truncation and correlated tool loss. Issue #804 reports that the Codex SubagentStop shell hook returns no JSON on native Windows without WSL, producing visible errors after subagents finish. Both are specific reports, not proof that ordinary macOS or Linux sessions fail.
GitHub showed 6,183 stars, 208 open issues and pull requests, and a last push on August 26, 2026. Release v1.20.0 arrived July 20 with search ranking, cloud, TUI, import, and sync fixes. Engram is moving quickly and documents its internals unusually well. Our 40-second build makes it easy to trial locally, but the 476-second failing suite and client-specific reports argue for starting with one machine, one project, and a tested backup of the SQLite file.