
Devin Memory
io.github.Icaro0310v0.3.0Updated Oct 4, 2026
Anti-poisoning memory for agents: provenance, conflicts, quarantine gate.
Overview
A local memory store for agents that screens every write, quarantines suspicious entries, and records where each memory came from.
- What it does
- Provides a persistent memory store with tools such as retain, recall, screen, list, retract, supersede, quarantine, release, approve, conflicts, prime, verify and extract. Every write is screened for secret and injection patterns, and suspect entries go to a quarantine lane until a human releases them. Entries carry claimed session provenance that can be audited read-only against a sessions.db, and conflicting facts are linked rather than overwritten. Only active entries appear in recall, prime and export.
- When to use it
- Use it when you persist agent memory between sessions and want it distrust-by-default, with screening, human review and versioning instead of silent edits. It also fits when you need to answer where a stored memory came from, or when you want export compatibility with an existing memory JSONL format.
- Requirements
- Runs locally as a stdio MCP server, installed with pipx or uvx from the PyPI package devin-memory-mcp. Needs Python 3.10 or newer. The store path is set with the --db argument or the DEVIN_MEMORY_DB environment variable, defaulting to ./memory.db. Session provenance auditing needs a path to a sessions.db supplied with --sessions-db. No authentication or network calls are declared.
Installation
In SourceWeft
- Open Devin Memory in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
devin-memory
Unofficial community project. Not affiliated with, endorsed by, or sponsored by Cognition AI. "Devin" is a trademark of Cognition AI.
Português (BR) · English
An anti-poisoning memory store for Devin: durable facts with provenance, versioning, and a quarantine gate — so agent memory can't be silently corrupted by a bad session or injected content.
The problem
Agent memory is a poisoning vector. Any tool that persists "facts" between sessions can be corrupted by a single bad session — an injected instruction or a pasted secret becomes a trusted belief in every future session, with no review step and no way to answer "where did this come from?".
Prior art
- The Devin memory MCP (
retain/recall/reflectover.devin/memory/memories.jsonl) — append-only, no screening, no session provenance.devin-memoryexports to that exact line shape. - MemGPT / LangChain memory — persistence layers that optimize for recall, not for auditing or distrusting what was stored.
devin-memory adapts the memory-store idea; it adds the parts those tools
don't have: a quarantine gate and provenance back to real session rows.
What makes it Devin-native
- Side-by-side: every entry can carry
source_session_id+source_rowid, auditable against Devin'ssessions.dbviadevin-internals' read-only store — the memory MCP cannot verify that a claimed source session (or a specific message row) ever existed. The quarantine gate also screens every write for secret and injection shapes. - No-Devin: without
sessions.dbthere is no session provenance to audit — the extra disappears. - One sentence: it's a memory store that remembers where each memory came from — and quarantines suspicious ones until a human releases them.
Install
Python ≥ 3.10 and pipx are required. Windows (PowerShell): install pipx with py -m pip install --user pipx, run py -m pipx ensurepath, then reopen the terminal. Linux (Debian/Ubuntu): run sudo apt install pipx python3-venv and pipx ensurepath; reopen the terminal. Other Linux distributions should install pipx using their package manager.
For development:
Usage
MCP server
devin-memory is also a real MCP server (stdio) — the same retain/recall
pipeline with the quarantine gate on every write, callable from Devin,
Claude Desktop, Cursor or any MCP client:
Client config:
Tools: retain, recall, screen (dry-run the gate, no write), list,
retract, supersede, quarantine, release, approve, conflicts,
prime, verify, extract. Every tool returns structured data or a
{"error", "detail"} object — nothing raises through the transport.
DEVIN_MEMORY_DB works as an alternative to --db.
Learn from sessions with devin-learning
This companion CLI extracts candidate lessons from a sessions.db and writes
reviewable skill drafts. It does not install drafts into a workspace by default.
review is a dry-run unless --apply is given; review --apply moves rejected
drafts under _rejected/. The extractor reads session contents, so keep its
output private until reviewed.
Memory states
active · proposed (extracted, awaiting approve) · quarantined
(screened or manually flagged, awaiting release) · retracted (withdrawn or
superseded). Only active entries surface in recall/prime/export —
quarantined content is never printed and never recalled.
Conflicts, extraction and prime (heuristics)
- Conflicts — a
retainthat gives the opposite directive about the same normalized subject as an existing active entry is stored alongside it with aconflicts_withlink (devin-memory conflicts). The heuristic compares a stop-word-stripped "subject key" plus affirmative/prohibitive polarity — it deliberately misses reworded contradictions rather than mislinking facts. extractscans one session'smessage_nodes(read-only via devin-internals) for durable-knowledge signals — user corrections ("na verdade", "actually", "the right way"), preferences ("always", "never", "sempre", "nunca"), discovered commands (backticked known tools) and paths. Candidates are screened like any write: clean ones landproposed, suspect onesquarantined.--auto-approveskips the review step.primeemits a compact# devin-memory: recalled context (heuristic)block sized for a prompt hook. Entries scoped withretain --workspaceonly prime inside that workspace; entries written under a different machine profile never prime (the profile defaults tocorporate— fail-closed).
The store is ./memory.db by default — override with --db or
DEVIN_MEMORY_DB. It is the only store this tool writes to; Devin's
sessions.db, acp-messages/*.db and state.vscdb are only ever read.
Works with Devin alone (Devin-only mode)
devin-memory keeps a local memory store (JSONL) with provenance tracking and
a quarantine lane — no external memory service, no network calls. Both console
scripts (devin-memory and devin-learning) run on your machine only.
Honest caveat: write-time screening is a heuristic, not a guarantee — suspect entries land in quarantine for human review, so keep that habit.
Platform support
The memory store uses an explicit local SQLite path and the session database is
provided with --sessions-db; no platform-specific path is assumed. Windows
and Linux are supported and covered by CI.
Limitations
- Extraction is heuristic, and proposed by default.
extractlifts keyword-shaped sentences from one session into aproposedreview queue — nothing becomes active withoutapprove(or--auto-approve). For a richer lesson pipeline seedevin-learning. - The screen is a filter, not a guarantee. Pattern-based secret detection
and injection heuristics have both false positives (→ quarantine, one
command to release) and false negatives. Run dedicated scanners
(gitleaks,
devin-redact) too — this complements them. - Recall ranking is keyword-based, deterministic and documented — no embeddings or semantic search in M1.
- Provenance is recorded, not self-verifying.
retainstores the claimedsource_session_id/source_rowid;verifyaudits it against a realsessions.dbafterwards. A bad actor can claim fake provenance — the point is that it is checkable. - Quarantined supersessions still retire the old version. If the
replacement quarantines, review the queue (
quarantine --release). - Not on PyPI yet — install from the repo for now.
When to use this
- You persist agent memory between sessions and want it distrust-by-default: every write screened, suspect entries quarantined for human release.
- You need to answer "where did this memory come from?" — entries carry
source_session_id/source_rowid, auditable viaverify. - You want memory versioning —
supersede/retractkeep a history instead of silent edits. - You want to stay compatible:
exportwrites the Devin memory MCP'smemories.jsonlline shape.
When NOT to use this
- You need semantic recall — ranking is keyword-based, no embeddings.
- You expect the screen to catch everything — it is a heuristic filter; run dedicated scanners (gitleaks, devin-redact) alongside.
- You expect
extractto read intent — it matches keyword signals and defaults toproposedprecisely because heuristics err.
FAQ
How do I stop agent memory from being poisoned by a bad session? Use devin-memory retain instead of appending to a raw store. Every write is screened for secret and injection shapes — suspect entries land in quarantine and only become active after a human runs quarantine --release <id>.
Can devin-memory prove a memory came from a real session? Yes, via recorded provenance. retain --source-session <id> --source-rowid <n> stores the claimed origin, and devin-memory verify <id> --sessions-db <path> audits it read-only against Devin's actual sessions.db — a fabricated source is checkable, not silently trusted.
Does devin-memory replace the Devin memory MCP? It complements it. The MCP is append-only with no screening; devin-memory adds quarantine, provenance and versioning, and devin-memory export --out memories.jsonl produces the exact line shape the MCP reads.
License
MIT — see LICENSE.
Source: README.md at commit c26c5cd
Tools
0Version history
1- v0.3.0LatestOct 4, 2026
