memory-fork, in use

Memory

memory-fork

It keeps your auto memory up to date in the background after every turn, so the main session never stops to write it.

ray-amjad/claude-code-modsUpdated

What it does

memory-fork takes memory writing out of the main session. After every turn, it decides whether Claude's auto memory needs a change, drafts that change in a fork of the session and writes the files itself. The main session is told that memory is handled, and its own Write and Edit calls into the memory folder are refused.

If you ask Claude to remember something, it just acknowledges it, and the save happens when the turn ends.

Using it

There's nothing to set up. Once it's installed, a band above the prompt shows each run: Memory: updating with the reason, then the lines added and removed and the files that changed. The band has Open and Hide buttons.

Open shows a pane listing every run this session, each file with its own added and removed line counts, and the session total at the top. /memory-fork opens the same pane. Turns where nothing was worth saving show as "nothing to remember", and a failed run shows the reason.

How it works

After each turn that ends with an answer:

  1. Haiku judges the turn. It reads the last exchange and your MEMORY.md index and answers SKIP or UPDATE: <what to save>. It's told memory is for facts that help future sessions and that the repo itself doesn't record: who you are, feedback you gave, project decisions and pointers to outside resources. Routine work and things only this conversation needs get a SKIP.
  2. A fork drafts the change. $.model.fork replays the session's own transcript, served from the prompt cache, with the current memory files attached. Every tool is denied, so it can only reply with JSON listing files to write and files to delete.
  3. The mod writes it. Files are written with $.fs.write and deletions run as rm -f, only for bare *.md names inside the project's memory folder. MEMORY.md is never deleted.

If a turn ends while a run is still going, the mod queues one more run for when it finishes, rather than running two at once.

Why a model fork, not a subagent

The first version spawned a forked agent to write the files. In auto mode every agent spawn goes to the permission classifier, and the classifier gives no verdict on a spawn the user never typed, so every run failed. A tool-less $.model.fork makes no tool calls at all, and the files are written by the mod's own code.

Limits

  • Because the mod's own code writes the files, the writes skip every permission prompt, in every mode. The file-name guard is the only limit on them. Read hooks/register.tsx before you install it.
  • There's no backup or undo. Whatever the fork writes replaces the old file.
  • Every answered turn costs a Haiku call, and every UPDATE costs a fork of the session.
  • The memory folder is ~/.claude/projects/<project>/memory, worked out from the session's working directory. CLAUDE_CONFIG_DIR is respected.
  • The fork has to reply with JSON. If it doesn't, the run is marked failed and nothing is written.