I built an open-source chat memory protocol for people who want useful continuity across AI conversations without pretending every ChatGPT surface can access local files.
The core idea is simple: use on-device memory only when the current environment actually provides filesystem access. When it does not, the assistant should say so clearly and continue without inventing reads or writes.
What it includes
- A routing protocol for universal memory and chat-specific memory
- Person-separated records so one person’s preferences do not silently transfer to another
- A reusable template for an owner-specific live file such as _CHAT_MEMORY.md
- Platform-aware rules for macOS, Windows, Linux, web, mobile, and other ChatGPT surfaces
- Guardrails against storing passwords, API keys, tokens, payment details, or private data
- A .gitignore that keeps live memory files out of public repositories
The important boundary
A local memory file is useful only when the assistant can genuinely read and write it. On web, mobile, or restricted environments, the protocol treats local memory as unavailable instead of simulating access.
That makes the system less magical—but more trustworthy.
The full protocol, template, and cross-platform guidance are available here:
👉 chat-memory-protocol on GitHub
I’d love feedback from people building AI assistants, privacy-first workflows, or long-running projects: how do you handle continuity without creating hidden or inaccessible state?
Top comments (1)
The availability boundary is the right starting point. I would make each memory record carry an explicit scope, retention date, and deletion receipt as well, so continuity remains inspectable after a surface changes or a project ends. “Could the assistant access this?” and “should this still exist?” are separate checks worth keeping visible.