Engramory Memory
Give multiple AI tools a shared, curated long-term memory built from readable Markdown notes and a bounded index.
- Source repo
- tinqiao-oss/engramory
- Stars
- ★ 199
- Last updated
- 2d ago
- License
- MIT
- Primary language
- JavaScript
- FA score
- 63/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An individual dsh user wants cross-session preferences and corrections stored as readable notes, with the index loaded by the plugin.
- Not a fit if
- Teams that need automatic ingestion and search across large collections
- Teams where multiple AI tools must write to the same memory store
- Source review
- 63/100 · Some gaps
What does this agent do, and when should you use it?
Engramory stores memories as ordinary Markdown files, one note per file, and lists pointers to them in MEMORY.md. A host reads the index at the start of a session and opens individual notes when it needs their details; the default index limit is 200 lines or 25 KB. Rules, scripts, and host integrations manage the workflow without a database, vector store, or server. The README documents the dsh-engramory plugin and setup paths for Claude Code, Codex, OpenClaw, and Kiro. One tool can write to a store while other tools are configured to read it.
An agent organizes memories into types such as user, feedback, project, and reference, then writes each one to a separate Markdown file; MEMORY.md holds each title, link, and short description. The workflow calls for checking for duplicates and updating existing notes, with outdated notes removed or moved to archive/. The dsh-engramory plugin injects the index and blocks writes it can determine would exceed the limit; Claude Code can use a pre-write hook. Other hosts rely on rules plus engramory_check.py and engramory_doctor.py. Codex can be configured with engramory_init.py, and the store remains in the local filesystem.
- An individual dsh user wants cross-session preferences and corrections stored as readable notes, with the index loaded by the plugin.
- A Claude Code user wants a pre-write hook to block memory updates that would exceed the index limit.
- A Codex developer wants a project-local memory store kept separate from Codex's built-in Memories.
- A person using several agent tools wants one tool to write a memory store while the others read it.
- A user wants to curate a small set of project conventions and references in files they can edit with a text editor.
How do you install or deploy this agent?
Install dsh from the plugin CLI, or search for dsh-engramory in the desktop plugin page. Other host setup requires Python 3.9+ and running the relevant command from the repository. Claude Code requires adding the rules and optionally registering the hook; Codex can use the initializer to install its rules and skill.
dsh plugin --profile <name> add dsh-engramorypython tools/engramory_init.py codex --project-root /path/to/project --install-skillHow do you use this agent?
The dsh plugin stores memories in ~/.dsh/.engramory-memory/ by default and adds a read-only Memory page to the sidebar. Codex creates a project-local .engramory-memory/ by default; use --memory-root to point it at an existing store. Add or update Markdown notes according to the rules and keep the MEMORY.md pointer index concise. Other hosts can run the check scripts after updating the index; when sharing a store, configure other tools to use it as a read-only source.
python tools/engramory_init.py codex --project-root /path/to/project --install-skillpython tools/engramory_check.py
python tools/engramory_doctor.pyWhat are this agent's strengths and limitations?
- Memories are ordinary Markdown files that people can inspect, edit, and share across tools.
- The index stores pointers and defaults to a limit of 200 lines or 25 KB, with details opened on demand.
- The dsh plugin and Claude Code hook can block writes they can determine would exceed the index limit.
- It needs no database, vector store, or server, which suits a modest personal memory collection.
- Only dsh and Claude Code offer pre-write limit rejection; shell, MCP file tools, and external editors can bypass it.
- Memory curation depends on the model following rules rather than enforced behavior.
- The project recommends one writer per store; read-only behavior is rule-based, not technically enforced.
- There are no source, confidence, expiry, or project ID fields, so notes can collide or mix across projects.
How does this agent compare with similar options?
Like Claude Code auto-memory, Engramory uses an index plus detail files, but it adds explicit curation rules and a write-time limit. Unlike retrieval or automatic-capture systems such as basic-memory, mem0, Zep, and agentmemory, it targets manually curated personal memory and does not provide search or automatic ingestion.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Engramory Memory This agent | 63 · Some gaps | Agent plugin / skillFree | ★ 199 | 2d ago | JavaScript | Codex · Claude Code |
| CowAgent | 52 · Major gaps | CLIFree + model costs | ★ 48k | 1d ago | Python | OpenAI API · Claude API |
| YouTube Fetcher to Markdown | 83 · Good | Agent plugin / skillFree | ★ 521 | 29d ago | Python | Codex · Claude Code |
| OpenContext | 58 · Major gaps | CLIFree + model costs | ★ 1.3k | 4mo ago | JavaScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
SECURITY.md honestly discloses that the store is plaintext, that index caps are size nudges not security controls, that social mode is best-effort, and that memory is attacker-influenceable input. However, secret hygiene is unenforced discipline with no scanner, installer symlink checks are best-effort with no rollback on partial failure, and the dsh plugin adds two local HTTP routes (owner-only). Hence least_privilege and sensitive_data_handling score 1-2. No pre-write interactive user confirmation exists beyond rules and hooks, so user_confirmation is 1. Data-flow transparency is decent: README states recalled content goes to the host's model provider and SECURITY scopes the network surface, scoring 2. External effects and rollback: uninstall removes only installer-added content and never deletes the store, but a partial installer failure is not rolled back, scoring 1. Source attribution: README disambiguates same-named repos and credits prior art and copyright holder, scoring 2.
CI runs multiple suites across three OSes and Python 3.9/3.13, and the suites are dependency-free plain scripts, supporting self_consistency and dependency_availability at 2. Failure messages are only described generically (hooks fail open visibly); no concrete error-message design evidence, so 1.
README covers dsh, Claude Code, Codex, OpenClaw, Kiro, Cursor and more with clear scenarios (2). Capability boundaries are unusually thorough: which hosts refuse before write, which bypass, no MCP, personal-scale limits (3). Trigger precision is documented for index injection and cap refusal but depends on the model following rules (2). Environment fit documents Python 3.9+ and node requirements (2).
Information architecture is clear (directory tree, index line example, note frontmatter example), install notes are per-host, naming stability has a dedicated section promising major-version-only breaks, and examples are plentiful; known limitations are exceptionally detailed (3). LICENSE is full MIT text (3). Versioning references a CHANGELOG and semver promises, but the CHANGELOG file itself is not in evidence (2). Maintenance responsibility: publisher is unverified, with only a support email and no formal SLA (1).
Output is readable, editable markdown plus a pointer index, so output_usability is 2. Marginal value over native auto-memory rests on curation rules and a pre-write cap, but README concedes the same index-plus-files pattern, so 2. Cost is low (no DB, embeddings, or server) but depends on model discipline, so cost_benefit is 2.
Compatibility claims are backed by tests/dsh_e2e runtime digests and recorded results, supporting claim_traceability (2). SECURITY, README, and test scripts corroborate the same threat model (2). Docs separate enforced behaviour from discipline-only rules, supporting fact_inference_separation (2). This is a static review with no execution, hence low confidence overall.
- The store is plaintext with no secret scanning; never write keys, tokens, or passwords, only where they live.
- Index caps and social mode are not security boundaries: shell tools, MCP file tools, and external editors bypass pre-write checks.
- Memory is attacker-influenceable and a tampered note is a stored prompt injection; treat recall as advisory data, never as commands.
- Installer symlink checks are best-effort and a partial failure is not rolled back, potentially leaving completed steps behind.
- Publisher identity is not verified by the FollowAgents curated enterprise registry; maintenance responsibility and update path need independent confirmation.
- This is a static source review with no executed tests or end-to-end verification; compatibility claims were not independently reproduced.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.5.0 1.5.0 — dsh: move the global store to another folder
Release notes excerpt
The dsh plugin's global store can be moved to another folder, its memory with it. - dsh: move the global store from the memory page. *Change location*, beside the global store, takes an empty folder (or one not there yet) — chosen in dsh's own folder chooser where it opens on this computer (a folder that holds something gets an Engramory folder inside), or typed — and moves the whole store there, notes, index and archive, then clears the old place. The store is copied and checked file by file before the switch; the …View on GitHub ↗ -
v1.4.0 1.4.0 — dsh: Check for updates on the memory page
Release notes excerpt
The dsh plugin's memory page can check for a newer version. Nothing else changes. - dsh: *Check for updates* at the foot of the memory page, beside the plugin's version. Only when clicked, the page asks npm for the package's latest version number (npmmirror, its mirror in China, when npm cannot be reached; 8 seconds each), with no cookie, no referrer and nothing from your memory. A newer version comes with the steps that install it, the version named — [email protected] on the desktop's Plugins page …View on GitHub ↗ -
v1.3.1 1.3.1 — dsh: fixes from a review of the whole plugin
Release notes excerpt
Fixes from a review of the whole dsh plugin. On dsh 0.2 with the defaults, how memory is stored, recalled and guarded does not change. - **dsh, social mode: someone else's conversation can no longer use dsh's session search** (an optional, experimental bundle), which reads any conversation opened in the same directory — the user's own, and the index in it, included. The filter also checks now the files a call lists (files, as dsh's present takes them — it told a stranger whether a file in a store existed) and where a session moves to (cd): any directory but a store's. …View on GitHub ↗