Open Source a Professional One-Click Backup Tool for All Memories of Codex and Claude Code

Introduction

Agent’s memory assets are increasingly becoming our core assets, and these should not be held hostage by closed-source software. The best approach is to take control ourselves. Why call it a professional backup tool? Because we’re not just casually backing up a few files — we’ve designed it so it’s instantly usable in any Agent, with no information leakage!

This article details the current memory system modules of Codex and Claude Code, then designs a one-click memory backup program. It covers the technical selection rationale, specific usage methods, and how to further mine these assets. Fully open source — feel free to try it out!

Currently, the best AI agents are undoubtedly Claude Code and Codex. As we use them more deeply, we want the agent to understand us better, so we typically enable their built-in memory features. These two apps actually contain valuable information about us.

These are memory: it remembers how you prefer to communicate, how to run tests for a particular project, which repositories had pitfalls before, which commands not to try again, which expressions you dislike when writing articles, and that when researching open source projects you should first look at the local code.

The problem is that both Codex and Claude Code are closed-source tools.

We can see some local files and read official documentation, but we cannot see the complete logic of memory generation, filtering, recall, and injection. After a tool update, the format may change; when switching machines, some directories might be missed; if an account or product strategy changes, whether certain memories can still be used is not entirely under user control.

More importantly, if someday our account is lost, those valuable data become unusable — that’s a real shame!

Another key point: in the future we will certainly have more than one or two agents. How to connect them, without having each agent reiterate our preferences, is also crucial.

So I decided to build something: retrieve the memories already accumulated locally by Codex and Claude Code, and turn them into a local, readable, searchable, and portable memory archive.

This program only reads the memory directories of Codex and Claude Code, and does not modify the original files. It is only responsible for backup, anonymization, archiving, and compilation.

Know yourself and know your enemy. Before making technical selections, let’s first look at the current situation — what do Codex and Claude Code memories look like?

What Does Codex Memory Look Like?

Codex’s memory is more like a local recall cache, mainly for Codex’s own use.

On my machine, the configuration looks like this:

The local directory structure is roughly:

Several types of files have different roles:

For example, a certain Codex “skill” (this is different from our general concept of skills — it’s generated by Codex itself, somewhat similar to Hermes’ logic) might remember: when the user shares a WeChat public account link, first call a local tool to convert to Markdown; when making a financial morning newsletter, which script to run, which JSON files to save, and how to verify links.

This kind of content is very useful. It’s essentially a work manual Codex writes for itself.

But the problem is obvious: it primarily serves Codex itself, and external programs can hardly treat it as a stable, structured memory store.

What Does Claude Code Memory Look Like?

Claude Code’s memory is more file-oriented.

The most basic is CLAUDE.md. It’s suitable for long-term rules, project commands, code style, and team conventions. Common locations include:

There is also a set of automatic memories. It typically looks like this:

MEMORY.md is an index, containing only titles and a brief description. The actual content is in topic files. Topic files often have YAML frontmatter, e.g., name, description, metadata.type, originSessionId.

This design is quite suitable for archiving. The index is lightweight, the main content is readable, and the source is clear.

Technical Selection

Considering the current situation and requirements, I want a product that addresses the following pain points:

• Local long-term storage
• Preferably readable directly as Markdown
• Preserve original source paths for traceability
• Include hash deduplication and version snapshots
• Distinguish between user memory and agent memory
• Support search, with ability to later integrate vector and hybrid search (not just storage but also usage)
• Not be tied to any single closed-source tool
• Support incremental data updates

During research, I looked at solutions like Mem0, OpenViking, OpenHuman’s memory module, and MemOS.

Each has its strengths:

For example, Mem0 is more of a productized memory service. OpenViking is more like an Agent OS with a virtual file system and context organization capabilities. OpenHuman’s llm-wiki approach is great for crystallizing structured knowledge. MemOS is also more systematic in modeling memory objects.

But for the scenario of “backing up and organizing personal Agent memories,” all of them felt a bit heavy. Some solutions require running a service by default, some depend on specific databases or frameworks, and others are more like a full Agent protocol or runtime.

My need is simpler: first, fully, safely, and readably retrieve the memory assets from closed-source tools like Codex and Claude Code, forming a local, long-term maintainable memory repository.

I considered developing my own solution, but there could be omissions. Which vector database to use? How to organize different memories? How to quickly search and scale? All these need to be considered.

Finally, a friend recommended a recently popular open-source repository that I found very suitable for local memory storage: EverOS.

EverOS’s approach closely matches my needs:

Its directory model also fits this task:

My idea is: users/ for long-term preferences and working styles; agents/codex for Codex’s historical task experience; agents/claude-code for Claude Code’s project memories and skill cards.

Development: What everos-memory-archive Can Do

After import, the directories are separated:

I made a distinction between CC and Codex, which also helps with restoration and future consolidation. sources/ holds anonymized original snapshots, records/ holds organized Markdown cards. *.versions/.md keeps immutable versions. unified_index/ contains unified indexes and reports.

compiled/ is a compilation layer added later. It further organizes the raw materials from the archive into more usable Memory Packs.

How to Use

The above may seem complex, but it’s actually simple to use — we’ve already packaged it for you.

The one-click script is already in the repository:

A one-line skill template is also in the repository:

Going Further: Memory Pack

The archive layer solves “retrieval, searchability, traceability.”

But to truly make it usable by an Agent, we need an additional layer!

I added a local rule compilation command:

It generates:

This version does not call any LLM or request any remote API. It simply selects candidate content from the archive records and manifest according to rules.

The advantages are: fast, local, reproducible, and no additional information leaked to remote models.

The downside: it doesn’t perform true semantic deduplication, conflict resolution, or abstract summarization. For example, two memories expressing the same preference might both be retained; if a sentence doesn’t hit a keyword, it might be missed. — For higher precision, you can use an LLM to assist in organizing.

The purpose of each file:

For example, when starting a new Agent, before the first conversation, read bootstrap_context.md — at least it will know my basic preferences, common workflows, and which projects have historical context.

Backup process design:

What’s the Use of This?

From now on, memories no longer lie solely in the proprietary directories of closed-source tools.

When you change machines, tools, or Agents, you can take these memories with you.

You can also audit them: what exactly did the tool remember? Which memories came from where? When were they imported? What is their hash?

More interesting is the next layer: turning memories into reusable work assets.

For example:

• Give project_cases.md to a new Agent as project recovery material.
• Put bootstrap_context.md into a new tool so it knows how you work from the start.

That’s where I think the most value lies.

Models will change, IDEs will change, Agent frameworks will change. But the long-accumulated personal context, project experience, and working style should belong to the user themselves.

What this program does now is simply retrieve these things from tool directories and turn them into a local, readable, traceable memory asset.

Finally, thanks to EverOS for being open source — it helped me complete this project quickly!

Attached:

EverOS Open Source Address: https://github.com/EverMind-AI/EverOS

This Project Open Source Address: https://github.com/cclank/everos-memory-archive

Polished for a long time, creation is not easy. Welcome to star ~