| FMRS | 59 / 100 · C | 76 / 100 · B |
| Reliability | 10 / 20 | 13 / 20 |
|---|
| Security and permissions | 12 / 20 | 14 / 20 |
|---|
| Maintenance | 12 / 20 | 18 / 20 |
|---|
| Documentation | 11 / 20 | 17 / 20 |
|---|
| Setup experience | 14 / 20 | 14 / 20 |
| Best for | - Developers who use several MCP-compatible AI coding tools and are tired of re-explaining themselves.
- Users who want memory and identity data to stay on their own machine, inspectable and editable.
- Individuals or small teams long-term-accumulating quality standards, architecture decisions, and technical lessons.
- Vibe-coding workflows that need continuity across sessions, tools, and projects.
- Users who accept human review gates in exchange for local data sovereignty.
| - Teams that want an AI assistant to directly operate on GitHub repos and collaboration workflows
- Users already in the GitHub Copilot ecosystem who want a zero-deployment remote option
|
| Not for | - Multi-person collaboration, team-shared memory, or centrally managed server deployments (this is a personal identity layer).
- Anyone needing vendor SLAs, enterprise support, or a commercial license (AGPL-3.0, no separate commercial license).
- Storing passwords, API keys, or customer PII — the project explicitly advises against it.
- Users whose primary need is agent task memory/session history and who have already chosen Mem0/Zep/Letta-style tools.
- Scenarios demanding hardened access control over plaintext local files: restricted_fields and the governance layer are not encryption or a true ACL.
| - Scenarios where you don't want the assistant to have write access to repos (enable only read-only toolsets)
- Environments with strict network isolation for private repos that can't reach the official remote endpoint
|
| Required permissions | - Read and write JSON/Markdown files under the local Engram data folder (default ~/.engram/).
- Write AI-client MCP config and instruction files during engram setup, only after your confirmation (backed up first; decline leaves them untouched).
- Write a local-only audit log at ~/.engram/audit.log, enabled by default (opt out with ENGRAM_AUDIT=0).
- Optional: read_web_content fetches a URL you provide, via a local sidecar or the built-in reader.
- Optional: ENGRAM_TOOLS=all exposes all 59 tools to the model, including owner/admin export, import, and trust-management interfaces.
- Optional: remote SSE mode requires ENGRAM_AUTH_TOKEN and should sit behind a TLS reverse proxy.
- Optional: telemetry is off by default; enabling remote telemetry or feedback is separate explicit opt-in and sends counts only.
| - A personal access token (PAT) or OAuth App token; effective scope depends on the token's own permissions
- Enabling toolsets like actions/issues/pull_requests grants write access — request tokens on a least-privilege basis
|
| Risks and side effects | - Data is plaintext JSON/Markdown by default, so any process that can read ~/.engram/ can read your data; field-level encryption is optional, not the default.
- The project explicitly warns against storing passwords, API keys, or client PII in Engram.
- restricted_fields only reduces what is emitted in cold-start context — it is not encryption or a real ACL.
- Caller identity comes from MCP environment variables rather than cryptographic authentication, so governance is a practical local policy boundary, not a hardened sandbox; the MCP spec does not pass tool identity.
- Export outputs (export_engram, get_identity_card, export_knowledge_report) contain full or broad content and should be treated as sensitive files.
- import_engram mutates the local store: always preview with dry_run=True first; applying requires explicit --apply --yes.
- Concurrent writes rely on a file lock plus atomic replace; network-filesystem edge cases are not guaranteed.
- Playbook auto-extraction redacts sensitive info before staging (keys, tokens, absolute paths, emails), but drafts remain untrusted until you confirm them.
- Remote deployment without proper HTTPS and token handling can expose identity data.
| - Write toolsets (creating/merging PRs, triggering workflows) can cause accidental changes if the token is overscoped — try a read-only toolset first
- In hosted mode, credentials travel via the Authorization header — make sure the client-to-api.githubcopilot.com connection is trusted
|
| Supported clients | Claude Code, Codex, Cursor, Claude Desktop, Hermes, OpenClaw, Windsurf, GitHub Copilot, Cline, Roo Code, Amazon Q, Augment, Zed, Trae, Tencent CodeBuddy, ChatGPT / Gemini / Kimi | Claude Desktop, Claude Code, VS Code, Cursor, Windsurf, JetBrains IDEs, Zed, Amp |
| Tools | 58 | 15 |