Your AI Coding Memory Contains Your Decisions and Mistakes: A Privacy Checklist for Developers

Private AI coding memory self-hosted is a memory store for your coding agents that runs on hardware you control, is encrypted with a key only you hold, and needs no vendor account. To set one up, install a local memory tool, keep the key in your OS Keychain, and verify what leaves your machine.

The rest of this article is a checklist for doing that. It is written for developers who use Claude Code, Cursor or Codex every day and want to know what those tools are quietly remembering.

AI coding tools are now routine. The Stack Overflow Developer Survey 2025 reported that 84% of respondents use or plan to use AI tools in their development process. A memory layer sits underneath that habit and records what the tools learn about you.

It holds decisions and the reasons behind them, such as "we dropped Redis for SQLite because the cache was never the bottleneck." It holds file paths, service names and internal conventions. It holds preferences, like "always use pnpm."

It also holds your mistakes. A memory of "the deploy failed because the staging token expired" is useful next week. It also describes your infrastructure to anyone who can read it.

Then there are secrets in passing. You paste an error log with a connection string, and the session captures it. This is not far-fetched. GitGuardian's State of Secrets Sprawl 2025 report counted 23.8 million new secrets leaked on public GitHub in 2024. Any pile of developer text that gets copied around will collect credentials.

Treat a coding memory like a private notebook about your company. Decide where it lives before it fills up.

These work for any product, including ours. If a vendor can't answer one plainly, that is an answer.

Find out whether memories live in a database on your disk or on someone else's servers. "Local" should mean a file you can open, not a cache for a hosted service.

Encryption only matters if the vendor can't decrypt your data. Ask where the key is stored and whether anyone else has a copy. A key in the OS Keychain stays on your machine. A key in a vendor dashboard does not.

Look for any sync, telemetry or embedding calls. Ask what is sent, to whom, and in what form. Then confirm it yourself by watching network traffic for an hour.

A memory you can't inspect is a memory you can't trust. You should be able to list every entry, edit it, pin it and delete it.

Ask if you can export your data and whether the tool is open source. If the license is permissive and the store is a plain database, you can always walk away with your history.

At Open Agentic Brain & Memory (OpenAB), we built the self-hosted memory layer for Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta) around those five questions. Here is how each one is answered.

Where it runs: memories sit in a local SQLite database on your machine.

Who holds the key: the memory is encrypted with age, and the key lives only in your OS Keychain.

What leaves: if you sync across machines, an encrypted blob goes to a Release asset on your own private GitHub repo. There is no OpenAB account and no OpenAB server.

Control: a local control panel lets you read, edit, pin or delete every memory.

Leaving: OpenAB is free and Apache-2.0 licensed.

The practical effect is simple. If our website disappeared tomorrow, your memory would keep working. If someone got hold of your private repo or a GitHub token, they would find an encrypted file and nothing readable.

This is also why "private" needs a qualifier. Your memory is private from us and from the sync host. It is not private from you, from other software running as your user, or from the model provider once a briefing is sent into a chat. The briefing is capped at 2,000 tokens, so what any tool sees at session start is bounded.

Encryption protects memory at rest. It does nothing about what goes into memory in the first place. That part is habit and review.

Keep real credentials out of chats. Use environment variables and tell your agent the variable name, not the value. If a secret does slip in, find the memory in the control panel and delete it.

There is a second risk. A poisoned memory can steer an agent. If a tool writes something wrong into memory, every other tool inherits it. This is a good reason to prefer a store where you can read and edit entries.

Deleting should be boring. In the control panel you can remove a single memory or a whole project's worth. After that, recall no longer returns it and it no longer appears in briefings.

Check your synced copy too. The encrypted blob in your private repo reflects the state at the last sync. After a large cleanup, sync again so the stored copy matches. Old Release assets can be deleted from GitHub directly.

The key is the harder topic. Only you hold it. If you lose it, nobody can recover your encrypted memory, including us. That is the cost of having no vendor in the loop.

Plan for it. Back up the key in a password manager before you rely on sync. A lost key is annoying, not catastrophic, because you can start fresh and let new sessions rebuild memory. You would lose the history, not the ability to work.

You can do this in an afternoon. Start with whatever tool you use most.

List your tools. Write down every AI coding tool and machine that stores or reads memory.

Find the stores. Locate the file or service holding each one. Note whether it is on disk or hosted.

Read 50 entries. Skim for tokens, hostnames, customer names and anything you would not paste in a public issue.

Delete what shouldn't be there. Then rotate any credential you found. Deleting a memory does not un-leak a secret.

Watch the network. Run your tools for an hour and note every outbound destination.

Check the key. Confirm where it lives and that you have a backup.

Test recall. Ask a question you know the answer to and see if the memory returns the right entry.

If you want to try this on a tool built to pass the checklist, install Open Agentic Brain & Memory (OpenAB) and run the audit against it. Recall over 10,000 memories takes 28 ms (p50), and the start-up briefing takes 84 ms (p50), so the privacy work does not cost you speed.

It can be, if you control where the data lives and who holds the key. Decisions are low-risk compared with credentials, but they still describe your systems. Prefer a local store, encrypted sync and a way to inspect every entry.

It is private from vendors, because the file never leaves your disk unless you sync it. It is not private from other software running as your user. Disk encryption and a locked screen still matter.

Yes. OpenAB needs no account and no server of ours. Sync is optional and uses your own private GitHub repo.

Yes. The OpenAB control panel lets you read, edit, pin or delete each one. If you sync, run a sync afterwards so the stored copy matches.

Anything you type can be captured as a memory, so treat chat as a place to avoid secrets. If one slips in, delete the memory and rotate the credential. GitGuardian's 2025 report shows how often leaked secrets stay valid long after they are exposed.

Nobody can recover the encrypted copy, including us. Back up the key in a password manager. If it is gone, you can start fresh and rebuild memory from new sessions.

Yes. OpenAB shares one memory across Claude Code, Cursor, Codex, Antigravity and Kilo Code (beta). Tell one tool something and the others know it.