Last Updated: 8/21/2026

Memory Bank and Sync

Overview

Jolli Memory keeps a copy of every memory on your own disk, and it can mirror those memories across your devices. This page explains the Memory Bank (the local copy), how to find and move it, and how cloud Sync differs from Share in Jolli.

Prerequisites

• The jolli CLI installed and Memory enabled in at least one repository.
• Sync needs a Jolli API key. If you are running bring-your-own-key only, the Memory Bank still works but Sync is unavailable.
• The AI conflict merge during a sync needs an Anthropic key.

What the Memory Bank is

The Memory Bank is a plain-Markdown copy of your memories, written to a folder on your disk.

Every time Jolli Memory generates a summary, it writes that summary to two places at once: the git orphan branch that stays with your repo (the source of truth), and the Memory Bank folder. This happens automatically on every commit. You do not turn it on, and you do not run anything.

Because the Memory Bank is just files on disk, you can open, read, search, and back them up with any tool - reading them needs no network and not even the extension.

Finding and browsing your memories

By default the Memory Bank lives at:

~/Documents/jolli/<repo>/

Each repository gets its own subfolder. Inside, there are three layers:

• A visible Markdown layer you browse. One readable file per memory, grouped by branch:

  ~/Documents/jolli/<repo>/<branch>/<slug>-<hash8>.md

• A hidden .jolli/ layer that holds the canonical JSON (summaries/, transcripts/, index.json). This is for programs to read, not for editing by hand.

• A generated _wiki/ layer - a browsable knowledge wiki (_index.md plus one page per topic) that jolli compile rebuilds after each commit. Read it freely, but do not edit it: it is regenerated and is never the source of truth.

Open any .md file in your editor, a Markdown previewer, or a file manager. Search it with your normal tools. You do not need the extension or a network connection.

If you delete a .md file by accident, you can bring it back:

jolli heal-folder

This re-renders the missing Markdown from the canonical JSON. It does not call the AI again, and it does not change your source of truth.

Reference IDs

Each memory carries a short reference id of the form JM-<number>, which gives you something quotable when you want to point a teammate at one. You will see it on a memory in the VS Code sidebar, in IntelliJ, and in the header of the memory’s page in the web app.

Two details are worth knowing:

• In the editors, selecting the id copies it to your clipboard. It does not open anything, and it does not expand the row it sits on. In the web app it is text you can read and select, not a link.
• On a detail view the id is always shown, falling back to the start of the commit hash for a memory that has not been pushed yet. In a collapsed list, the id appears only once a memory has been pushed, which makes it a quick way to see at a glance which memories have gone up.

Choosing where the Memory Bank lives

You can point the Memory Bank at any folder. This is useful if you want it on a different drive or in a specific location you back up.

In VS Code (or a fork such as Cursor or Windsurf):

1. Open Settings (the gear icon in the Jolli Memory view).
2. Go to the Memory Bank section.
3. Click Browse and pick a folder.
4. Click Migrate to Memory Bank.

In IntelliJ:

1. Open the Jolli Memory settings.
2. Go to the Memory Bank tab.
3. Set the folder path with the Browse button.
4. Click Migrate.

When you migrate, Jolli Memory copies your memories into a fresh folder at the new location. The previous folder is left in place on disk. Nothing is deleted, so you can remove the old folder yourself once you are happy with the move.

The folder setting is named localFolder. You can set it with jolli configure --set localFolder=<path> or from the editor Memory Bank settings. To relocate an existing Memory Bank, use the editor’s Migrate button: it copies your memories into the new folder and leaves the old one in place.

Checking that it is actually writing

jolli status always prints a Memory Bank: row, and the VS Code Settings page shows the same thing on its Memory Bank tab. (There is no equivalent in IntelliJ.) The row tells you which of these you are in:

• A folder path - the Memory Bank is writing there. The path shown is the resolved per-repo folder, not the parent you configured, because those two often differ.
• A folder path followed by (folder-only) - writing there, and only there, rather than also keeping the orphan-branch copy.
• Off — memories are stored on the orphan branch only - the visible folder is not in use. Your memories are still being kept.
• Not writing — this directory is not inside a git worktree - run the command from inside a repository.
• Not writing — the Memory Bank folder (<path>) is inside this repository; point it somewhere outside the working tree - the folder cannot live inside the repo it records. Move it with localFolder.
• Not writing — the Memory Bank folder could not be resolved (check $HOME) - your home directory could not be determined, so there is nowhere to put the folder.

The three “Not writing” cases are the ones worth acting on. Because the row is always printed, it is the quickest way to tell “my memories are not being written” apart from “my memories are somewhere I did not expect”.

Moving a repository’s storage to a local database

By default the source of truth for a repository’s memories is the git orphan branch, with the Memory Bank folder as the readable copy alongside it. A repository can instead be moved onto a local SQLite database, which then becomes the source of truth:

jolli cutover

This is one way. The cutover freezes the repository’s orphan branch, and jolli enable will not unfreeze it. Nothing is thrown away - the memories are carried across - but the repository does not go back to branch storage afterwards, so treat it as a decision rather than a setting.

Before you run it, check where the repository stands:

jolli cutover --status

And afterwards, you can confirm the frozen branch is genuinely at rest:

jolli cutover --probe

A probe exists because a frozen branch should stop moving. If it reports drift, something is still writing to it - usually an editor or a long-running process started before the cutover that is holding an older view of the storage. Restart your IDEs and any long-running processes after a cutover so they pick the new storage up.

Syncing across your devices

Sync copies your Memory Bank to a private space that only you can see, and keeps it consistent across every device you sign in to. Jolli calls this your Personal Space. The copy is private. It is not shared with your team. Under the hood, turning on Sync makes your Memory Bank folder a git working tree connected to a private Jolli-hosted remote - which is why sync conflicts behave like git conflicts, and why you should not nest the folder inside another sync tool (see below).

Sync needs a Jolli API key, so you must be signed in to Jolli. Sign in with jolli auth login, or with Sign In to Jolli in the editor. If you only use an Anthropic API key (BYOK) with no Jolli account, you cannot sync.

Running a sync

From the CLI:

jolli sync-memory-bank

In VS Code, open Settings, go to the Memory Bank section, and click Sync to Personal Space Now.

In IntelliJ, sync runs on its own (see below). You can also trigger it by hand from the Jolli Memory tool window: use the Sync to Personal Space button in the Memory Bank explorer toolbar, or Sync to Memory Bank in the overflow menu.

Automatic or manual, by editor

Whether sync runs on its own depends on the editor:

A sync status indicator shows one of four states: synced, syncing, conflicts, or offline.

Transcripts stay local unless you opt in

By default, sync mirrors your summaries, plans, and notes, but not your raw conversation transcripts. Transcripts can contain pasted code, tokens, or other sensitive snippets, so they stay on your machine until you opt in.

To include transcripts, turn on the syncTranscripts setting, or add the flag for a single run:

jolli sync-memory-bank --transcripts

This applies to both manual and automatic sync.

If you already use Dropbox, iCloud, or Syncthing

Do not put your Memory Bank folder inside a folder that another tool already syncs, such as Dropbox, iCloud, or Syncthing. Two sync tools fighting over the same files can corrupt them. If your Memory Bank folder is already inside one of those, turn one of them off. Let either Jolli sync or the other tool own that folder, not both.

When two devices disagree

If two devices push changes that conflict, Jolli resolves most of it for you. The internal index files merge automatically. For other files, it uses an AI merge when you have an Anthropic API key set, and falls back to asking you to pick a version.

When you run jolli sync-memory-bank in a terminal, the CLI prompts you on each conflict (keep mine, keep theirs, view a diff, or skip) and can show the diff inline. In a non-interactive shell (a git hook or CI), it cannot prompt, so it skips the conflicting files and prints their paths. Open them in your editor to resolve, then sync again.

Sync compared with Share in Jolli

These are different actions with different audiences. It is worth keeping them straight.

• The Memory Bank is a local copy on your disk. It is automatic, and nothing leaves your machine.
• Sync mirrors your Memory Bank to your private Personal Space, so your own devices stay in step. Only you can see it.
• Share in Jolli publishes one memory to your team’s Jolli Space, so a teammate can read it.

To share a memory, open the memory view for a commit and click Share in Jolli. To share a multi-commit story, squash the commits first, then share the combined memory.

When a memory goes up - one memory or a whole branch - the skills the work used travel with it as their own articles in the Space, next to the plans, notes, and references. That is the same skill record described in Supported AI Agents and Capture; the difference is that it is now published rather than only kept locally.

Squashing keeps your working context. Plans, notes, and references you activated during a session are archived onto the memory that git merge --squash and rebase -i squash or fixup produce, rather than being left behind in the working area for the next memory to pick up.

If a rewrite leaves a memory behind instead - the commit shows nothing while the memory sits on the hash that no longer exists - jolli doctor reports it and jolli repair-memory reattaches it. Run it with --status first to see what it would do. See Reference.

Turning off pushing for one repository

Some repositories should never leave your machine even when the rest do. You can turn outbound pushing off for a single repo:

jolli push-control --disable

Memories keep being recorded locally, so nothing is lost while it is off. Only sending them to a Space stops. Run jolli push-control --enable to turn it back on, which also sends what was held in the meantime. With no flags, the command reports where the current repo stands.

The setting is per repository and applies to every worktree of it, because it is stored once per repo on your machine rather than in the working tree. A repository with no remote can only be reached from inside itself, using --cwd.

Both editors expose the same control. VS Code has it on its Settings page, on the Sync to Jolli tab under Outbound push per repo, with a row per repository. IntelliJ has it in Settings as a Push this repository’s memories to Jolli checkbox for the current repository. All three surfaces read and write the same choice. If you try to push from a repo that is turned off, it tells you so and points you back there. Repos with no remote do not appear in that list, since there is no remote to identify them by; use the command inside the repo instead. See Reference for the full flag list and the caveat about repairing the stored setting.

Troubleshooting

If sync is not working, start with:

jolli doctor

Common issues:

• Not signed in. Sync needs a Jolli API key. Sign in with jolli auth login, or with Sign In to Jolli in the editor.
• HTTP 403 on sync or share. Your Jolli API key was rejected for this workspace, often because it was issued for a different org or was revoked. Re-authenticate to get a fresh key.
• HTTP 426 Plugin Outdated. Your extension is behind the server. Update the VS Code or IntelliJ extension to the latest version.
• Conflicts that will not clear. Open the files listed as conflicting, keep the version you want, and sync again.

For the full list of config keys and more troubleshooting, see Reference.

Related

• Getting Started with Jolli Memory - install, sign in, and your first Memory.
• The Local Dashboard - browse the same memories in your browser with jolli dashboard.
• Reference - config keys, including localFolder and syncTranscripts.
• Jolli Spaces - the team-side story once you publish a Memory.