Engram Blog · Published September 22, 2026

You Decide What Engram Remembers — Down to a Single Message

A memory you can't control isn't yours. How to keep whole repos and individual sessions out of Engram, say "don't save this" mid-conversation, and delete what did get in — one message, one conversation, or everything.

A memory system earns trust in two directions. The obvious one is recall: what you saved comes back, verbatim, anywhere you work. The less obvious one matters more: what you didn't want kept is provably not there. Engram is built around verbatim, permanent storage — which is exactly why every layer of it has an off switch. This post is the complete map of those switches: how to keep things out of Engram in the first place, and how to delete what did get in, down to a single message.

Keep it out in the first place

If you run the Engram CLI with auto-capture, your Claude Code and Codex sessions sync to memory as you work. That's the point — until you cdinto a client's repo under NDA, a project with regulated data, or anything else that should never leave the machine. Three controls, from broadest to most surgical:

1. Exclude a repo or directory from capture

engram exclude add ~/code/client-project   # this tree is never captured
engram exclude add                          # shorthand: exclude the current directory
engram exclude list                         # see what's excluded
engram exclude remove ~/code/client-project # capture new sessions again

Any session whose working directory is at or under an excluded path is dropped before it touches the sync queue — nothing is uploaded, nothing is stored locally. Changes apply immediately; no daemon restart.

For a repo the whole team should keep out of memory, commit a .engramignorefile at the repo root — an empty file is enough. Every teammate's CLI honors it automatically, the same way .gitignoretravels with the repo. One person adds it; everyone's capture respects it.

2. Say it mid-conversation: “don't save this to engram”

Sometimes the session started fine and became sensitive. Type a line like “don't save this to engram” (or the explicit marker engram:ignore) anywhere in a captured session, and the whole session is treated as if it was never captured:

  • capture stops for that session, permanently;
  • anything still queued on your machine is wiped;
  • anything already synced is deleted from the server — and if you were offline when you said it, the deletion is retried until it succeeds.

Only yourmessages can trigger this — an assistant merely discussing the phrase can't switch your capture off.

3. In ChatGPT and Claude: saving is up to you

Connector apps have no auto-capture. Engram stores something when you ask — “remember this,” “save this chat” — so the control is simply that you don't ask. On team accounts, you can also keep a conversation out of the shared pool: conversations can be created with visibility: "private", visible only to you rather than org-wide.

What never gets stored, even when you save

Every write runs through automatic redaction: recognized API keys, tokens, and common credential formats are stripped before storage, so a pasted key doesn't quietly become a searchable memory. Redaction is a best-effort safety net, not a promise — for secrets you actually want to keep, use the zero-knowledge vault, which encrypts on your machine and never lets the server see plaintext.

Delete what did get in

Deletion in Engram is real deletion, at every granularity. A stored message lives in up to four places — the content store, the database row, the keyword index, and the vector index — and a delete removes all of them, then rebuilds the surrounding search index so the deleted content can't resurface in recall. Deletions are recorded in your account's audit log, and if you've set up webhooks, a message.deleted or conversation.deleted event fires.

Delete a single message

One bad paste shouldn't cost you the whole conversation. With an API key that has the delete permission (create one in your dashboard):

curl -X DELETE \
  https://mcp.getengram.app/api/v1/conversations/<conversation_id>/messages/<message_id> \
  -H "Authorization: Bearer $ENGRAM_API_KEY"

# → {"deleted": true, "message_id": "msg_..."}

The message's stored body, database row, and slice of the search index are all removed; the surrounding index window is rebuilt from the messages that remain. If you'd rather correct than remove — say a message is 90% worth keeping and 10% regrettable — PATCH the same URL with new content and the message is rewritten in place, re-redacted, and re-indexed:

curl -X PATCH \
  https://mcp.getengram.app/api/v1/conversations/<conversation_id>/messages/<message_id> \
  -H "Authorization: Bearer $ENGRAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"content": "the corrected text"}'

Message ids come back from get_conversation (or GET /api/v1/conversations/:id), so “find the message, then delete it” is two calls.

Delete a conversation

Three equivalent doors, all permanent:

  • CLI: engram conversations delete conv_abc123
  • API: DELETE /api/v1/conversations/conv_abc123
  • Any first-party MCP client (Claude Code, Cursor, your own agents): the delete_conversation tool

Everything under the conversation goes: every message body, every chunk, every vector, every tag. Deleting also frees storage against your plan's limit — memory never expires on its own, but you can always make room.

Delete everything

Account deletion lives in the dashboard: it schedules a full erasure with a 30-day undo window, after which an automated purge permanently removes every conversation, message, search index entry, and stored secret. If you want the wait skipped, email hello@getengram.appand we erase same-day — the details of what's deleted and when are public on our trust page. Export your data first (JSON, from the dashboard) if you want a copy to keep.

Why ChatGPT and Claude can't delete your memory

One deliberate asymmetry surprises people: connector apps can save and search, but they cannot delete. A connected model asking Engram to destroy memory is not a thing we allow — deletion requires you, through the dashboard, the CLI, or an API key you explicitly created with the deletepermission. The inconvenience is the feature: your memory can't be erased by a model's bad day, a prompt injection, or an overeager automation.

The point

“Verbatim and permanent” only works as a product if it comes with “excludable and erasable.” Keep whole repos out with one command or one committed file. Kill a session mid-conversation with one sentence. Remove one message, one conversation, or every trace of your account — and know that deletion means the content store, the database, and both search indexes, not just a hidden flag. Your AI's memory should be yours in both directions.