Skip to content
Mastering Claude

Home / A structured installation

A structured installation10 minApplication

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.

Figure 1

The pull, write, commit, push cycle

01
Pull
At the start of a session, pull the remote notes before reading anything else.
02
Writing
Add notes to the folder throughout the session, like an ordinary notebook.
03
Commit
Commit the written notes with a message that dates the batch.
04
Push
Push to the private remote at the end of the session.
05
Conflict
On a refused automatic merge, keep both contents and merge by reading, never force one version over the other.
The figure shows the order of the protocol's four gestures and the response to give on a merge conflict, keeping both contents rather than forcing one over the other.
Figure 2

Two memories that do not overlap

Keeping a trace between sessionsScopeTriggerWhat gets written there
Git versioned memory vaultShared across every machine connected to the same private remoteManual by default, explicit pull and push, or wired to hooksNotes written by hand by the user or by the agent on instruction
Native automatic memoryLocal to a single machine, shared only between the worktrees and subfolders of a single git repositoryAutomatic, fed by the harness during the session without interventionSession notes accumulated by the tool itself
The table compares the git versioned memory vault and the native automatic memory across three criteria: their scope, what triggers them and what gets written there.
Calibrate it yourself

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 to remember
  • 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.
Do this now

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.

Check the source

Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.