Home / A structured installation
Wiring file based memory to git
A memory folder versioned by git, with a private remote and a merge rule that keeps both contents rather than forcing one over the other, remains a technique to build yourself, distinct from the native automatic memory, which never leaves the local machine.
A memory folder stays a pile of text files as long as it lives alone on one machine: it disappears with the machine, and nothing lets you know who wrote what or when. Turning it into a git repository changes its nature. Add a private remote, and this folder becomes a vault synchronisable across several machines, with the history, the diff and the ability to go back to an earlier version that git already brings.
The protocol in four gestures
The protocol fits in a few words. At the start of a session, pull the remote notes before reading anything else. Then write during the session, like an ordinary notebook. At the end of the session, commit the day's notes, then push to the remote. On a merge conflict, the rule is never to force one version over the other: it is to keep both contents and merge them by reading, by hand, a little later. A throwaway repository illustrates the basic mechanics without touching any real folder.
mkdir demo-memoire && cd demo-memoire
git init -q
echo "note du jour" > carnet.md
git add carnet.md
git commit -q -m "premiere note"
git log --oneline
On a real vault, this sequence repeats at every session, with a pull added before writing and a push after the commit. A folder run through grep to spot a secret before the very first push prevents a forgotten credential from reaching the remote and then staying in the history, even after the file is later deleted.
What the native automatic memory does not replace
Claude Code now ships with an automatic memory mechanism, distinct from CLAUDE.md, that accumulates session notes on its own in a local folder. This mechanism deliberately stays local to the machine: worktrees and subfolders of the same git repository share a single automatic memory folder, but nothing is shared between several machines or cloud environments. The git protocol described here therefore keeps its reason for being precisely where automatic memory stops, as soon as a second machine or a shared remote comes into play. The two mechanisms answer two different needs and can coexist without getting in each other's way.
This protocol takes on its full meaning once connected to the session lifecycle events, in hooks and heartbeat, where the pull and the push stop being a manual gesture and become automatic.
The pull, write, commit, push cycle
Two memories that do not overlap
| Keeping a trace between sessions | Scope | Trigger | What gets written there |
|---|---|---|---|
| Git versioned memory vault | Shared across every machine connected to the same private remote | Manual by default, explicit pull and push, or wired to hooks | Notes written by hand by the user or by the agent on instruction |
| Native automatic memory | Local to a single machine, shared only between the worktrees and subfolders of a single git repository | Automatic, fed by the harness during the session without intervention | Session notes accumulated by the tool itself |
A developer adds a private remote to her local memory folder, commits ten notes written over the week, then runs git push to that remote from her main machine. The command finishes and returns control.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: This result establishes that the committed content was successfully transferred from this machine to the private remote at this moment.
What this does not establish: It does not establish that this content is already readable from a second machine, nor that a future push from this same machine will go the same way without a conflict.
The three most common miscalibrations
- Too broad The memory folder is now automatically synchronised across all of the developer's machines.
- Too narrow This result proves nothing, since a single push never demonstrates that a git remote works correctly.
- Beside the point This result shows that the content of the ten committed notes deals exclusively with the past week's work.
- A memory folder versioned by git is not a feature documented by Anthropic under this name, it is a field technique built with ordinary git tools.
- On a merge conflict in the memory vault, the rule is to keep both contents rather than forcing one over the other, then merging by hand.
- The memory folder is run through grep to spot a secret before the very first push, never after.
- Claude Code's native automatic memory stays local to the machine and does not synchronise across several machines, so it does not replace a git vault with a private remote.
Create a throwaway git repository for your memory folder, add a private remote to it, push a first commit, then write in a shared file the merge rule you will apply, keep both contents, never force.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Anthropic, memory and CLAUDE.md, scope of native automatic memory consultée le 2026-09-02