Last Updated: 8/20/2026

Jolli Memory in Your AI Agent

Overview

Jolli Memory ships as a plugin for three agents: Claude Code, Cursor, and Codex. Install it once and Memory’s tools and skills are available inside that agent, and the git hooks that build your Memory are set up for you as you work.

If you already use the Jolli CLI you do not need a plugin. Both do the same job for a repository, and whichever surface is newest drives that repository’s hooks. The plugin is the shortest path when one of these three agents is where you work.

The three plugins do the same job and differ in a handful of ways that matter in practice. Those differences are collected in one table below rather than scattered through the page.

Prerequisites

• Node 22.13 or later on your PATH. This is a hard floor, not a recommendation: the bundled runtime uses node:sqlite, which throws on import below it.
• A git repository. The plugin does nothing outside one.
• A full restart of the agent after installing. This is the most common reason nothing appears to happen.
• No Jolli account is needed to generate memories. Signing in is only for sharing to a Space.

Install

Claude Code:

/plugin marketplace add jolliai/jolli-claude-plugin
/plugin install jolli@jolli-marketplace

The first line adds Jolli’s marketplace, the second installs the plugin from it. In the desktop app, use + → Plugins → Add marketplace with the same source, then enable Jolli Memory under Manage plugins.

Cursor: add jolliai/jolli-cursor-plugin as a marketplace, then install Jolli Memory from Customize in the sidebar and choose the project or user scope.

If the marketplace appears but lists no plugins, check its title. Cursor resolves a marketplace imported from GitHub through its own backend against your team, and on an account with no team that can come back empty with no error. The tell is an entry named after the repository rather than Jolli Cursor Marketplace - that means its manifest was never read. Importing from a local clone takes an entirely local route instead: clone the repository, then use Add Marketplace → Import from Disk and point it at the clone.

If you also use Claude Code, expect to see two Jolli entries in Customize. Cursor imports your Claude Code marketplace automatically, so the list shows both:

Install from the one with Cursor in its name. They are different builds of the same product, and the Claude Code one does not work here. It fails silently, which is what makes it worth knowing. Cursor does run its hook, but that hook resolves the repository from its own working directory, which under Cursor is the plugin’s folder rather than yours, so it finds no repository and does nothing. Its MCP server also starts before Cursor knows which folder is open, so it answers about your home directory. The result is that nothing captures memory while the skills and the MCP server look perfectly healthy, and every recall and search succeeds and comes back empty.

Leaving it in the list is harmless as long as you do not install it. Removing it from inside Cursor does not stick, because the import runs again on the next window reload. To remove it for good, remove it on the Claude Code side, which also removes it from Claude Code:

claude plugin marketplace remove jolli-marketplace

Codex:

codex plugin marketplace add jolliai/jolli-chatgpt-plugin
codex plugin add jolli@jolli-marketplace

The install target is jolli@jolli-marketplace because that is what the marketplace’s own manifest calls itself. Note that Claude Code’s marketplace shares that name, so the second line looks identical across the two agents while the first line differs.

Each agent fetches the plugin itself, so you do not need npm. The Node requirement above is the same one the CLI and the editor extensions have.

How the three differ

The entries in bold are the ones that surprise people. All are covered below. On Cursor the MCP server is written only once the repository is opted in, and it registers disconnected: open Customize in the sidebar and enable jollimemory. The skills work either way, because each one names a CLI fallback.

Each plugin carries its own copy of Jolli, so there is no global CLI to install. It stays reachable at ~/.jolli/jollimemory/run-cli and takes the same arguments as jolli itself.

On Windows, that fallback path needs a bash shell. Most of what a plugin does runs through Memory’s MCP tools and is unaffected. But run-cli is a bash script, so it works in Git Bash and not in PowerShell or Command Prompt. If one skill fails with a command-not-found or a path error while everything else works, this is why: run your agent from Git Bash, or install the CLI with npm i -g @jolli.ai/cli and use jolli directly.

Turn it on for a repository

There is no enable command to run. After install, the plugin sets itself up the next time it starts a session in a git repository:

1. Install the plugin (above).
2. Fully restart the agent. In a desktop app, quit it completely (Cmd+Q) rather than closing the window. Setup runs at session start, so it does not take effect in a session that was already open.
3. On Codex, trust the hook first. See Codex asks you to trust the hook, below. Until you do, nothing in this list happens.
4. Open a session inside the git repository you want Memory for.
5. The plugin then installs Jolli’s git hooks into that repository, adds the jolli front door, and selects a way to generate your memories. It repeats this check every session, so it stays set up and repairs itself if something is removed.
6. Check the status skill to confirm. You should see hooks installed and an AI provider set.
7. Make a commit. The Memory appears shortly after the commit returns.

You do not need to sign in or add an API key to generate memories. Each plugin records its own agent as the tool that writes your summaries, so generation works with no credential. Signing in is only for sharing to a Space, below.

Each git worktree is set up separately, so a new worktree gets its own setup on the first session there.

Cursor asks first, the others do not

On Claude Code and Codex, step 5 happens in whatever repository the session names, automatically.

Cursor is deliberately different: it will not set up a repository you have not opted in. A repository that has never had Jolli enabled is left completely untouched - no git hooks, nothing written. The reason is that Cursor announces every repository listed in your sidebar when it starts, so setting them all up would reach repositories you had only ever browsed.

To opt a repository in on Cursor, open a chat in it and run /jolli, which is available everywhere, or /jolli-init directly. From then on that repository is maintained like any other: the plugin keeps its hooks current and re-points its skills after an upgrade.

Codex asks you to trust the hook

Codex will not run a new or changed hook until you review it, and Jolli registers exactly one: a SessionStart bootstrap. Open /hooks, review it, trust it, then start a new session.

Two consequences worth knowing:

• Until it is trusted, the skills appear but can do nothing. Git-hook installation, MCP registration, provider setup and the branch briefing all run from that bootstrap, as does the helper the skills fall back to. So even $jolli:init can only tell you to trust the hook and start a new session.
• A plugin upgrade asks again. Trust is recorded per hook file and event type, and an upgrade moves the hook to a new version-stamped path, so it is a new entry as far as Codex is concerned.

From the first trusted session the skills work. The MCP tools arrive one session after that, because Codex reads its MCP registrations when a session starts and the registration is written by the bootstrap of the session already running.

Your past reasoning arrives automatically

All three plugins give you a briefing without being asked. Once a repository has Memories, every new session opens with a compact [Jolli Memory — <branch>] block: the branch name, its recent Memories, the key decisions behind them, and any pinned plans. It runs about 300 to 500 tokens, so it orients the session without eating your context budget.

This is a plugin feature. Running the same agent with only the CLI installed does not produce it; you pull context on demand with Recall instead.

Two things to expect:

• Feature branches only. The automatic briefing is skipped on shared branches such as main and master; Recall vs Search lists the full set and how the match is made.
• A nudge to run Recall. On any day after your last commit the briefing adds a tip to run a full Recall; past three days it becomes a warning naming the number of days.

Skipping the automatic briefing never disables recall. Run the recall skill any time for a deeper pull, or pass it a branch name for a branch you are not on. See Recall vs Search.

Nothing seems to have happened

Work down these in order, checking the status skill after each to see whether it took effect.

If none of those is the cause, the problem is not plugin-specific. One thing worth ruling out: capture for your agent can be switched off in your configuration. It is on unless someone changed it, so this only applies if you or a teammate set claudeEnabled, cursorEnabled or codexEnabled to false. That same switch controls the briefing, so a repository with Memories and no briefing is worth checking here. If you also have the CLI installed, turn it back on with jolli configure --set <key>=true. For everything else - missing credentials, a stuck background worker, a summary that never generated - see Troubleshooting and FAQ.

Commands and skills

Every plugin offers the same actions. Only the prefix changes: /jolli: in Claude Code, /jolli- in Cursor, $jolli: in Codex. The table uses the Claude Code form.

Typing the bare front door - /jolli in Claude Code and Cursor, $jolli in Codex - opens a menu that lists what is available and runs the one you pick. It works in any window, whether or not a repository is open, which is what makes it the right starting point on Cursor.

Cursor and Codex add two more: local-run and remote-run, for running a Jolli Workflow from the conversation. Claude Code’s plugin does not carry them.

Where Cursor puts its skills is worth knowing if one seems missing. Six ship in the bundle and are there from the moment you install: init, login, logout, status, timeline, push. The other four - recall, search, local-run, remote-run - are placed per repository, so they appear once you have opted that repository in. They are split this way because Cursor pools every skill source into one flat menu, and bundling them would list each one twice in a repository that already has Jolli set up.

init is a convenience, not a prerequisite, except on Cursor where it is how a repository opts in. Memory generation is already set up by the time you could run it elsewhere; what init adds is signing in and binding a Space in one pass.

Each plugin also registers Memory’s MCP tools, so you can ask for recall or search in plain language instead of running a skill. For the tools and how they behave, see Use Your Memory from Any AI Agent (MCP).

Using the CLI rather than a plugin? Where the CLI installs skills itself - Codex, Cursor, Gemini CLI, GitHub Copilot, and OpenCode - it uses the unnamespaced forms (/jolli-recall, /jolli-search). Same actions, different names per host.

Signing in and sharing to a Space

Signing in is what lets you bind the repository to a Jolli Space and share memories with your team. After binding, a git push publishes that branch’s memories to the Space.

Run the login skill for your agent. This opens your browser and can take up to a minute. Two things to know:

• It is not needed to generate memories. Generation keeps running locally whether you sign in or not.
• Sharing needs a Jolli credential specifically. A Jolli sign-in or a Jolli API key can bind a Space; an Anthropic API key cannot. If you use your own Anthropic key for generation, you still need to sign in to share.

Run the logout skill to sign out. Your Anthropic key, if you set one, is preserved.

Which version am I running?

The status skill reports the plugin version, which is the version you installed from the marketplace. Each plugin carries its own copy of Jolli’s engine, and that copy has a separate version which the status output does not show. The two move independently, so the engine inside a plugin can differ from the jolli command line published on npm - usually because a plugin release lands on its own schedule rather than alongside a CLI release.

That distinction only matters when you are comparing behavior against someone using the CLI, or against these docs. To read the engine version, open the file for your agent:

~/.jolli/jollimemory/dist-paths/claude-plugin
~/.jolli/jollimemory/dist-paths/cursor-plugin
~/.jolli/jollimemory/dist-paths/codex-plugin

The first line is the engine version, and the second is where that copy lives. If the file is missing entirely, the plugin has not set itself up yet - see Nothing seems to have happened above.

What the plugin does not cover

The plugins cover Jolli Memory only. The jolli space, jolli site, and jolli workflow command families come from separate CLI plugins you install with npm, and none of the three agent plugins loads them - each carries a fixed surface. If you need those, install the CLI alongside the plugin you want, for example npm i -g @jolli.ai/cli @jolli.ai/space-cli. Memory Bank cloud sync and the knowledge wiki are also CLI-only.

You can run a plugin, the CLI, and an editor extension together - whichever surface is newest drives a repository’s hooks, so they do not fight. For which surface suits you, see Jolli Memory.

Other agents are supported too, just not as plugins. Gemini CLI, GitHub Copilot, OpenCode, Cline, Devin, Antigravity and Kimi Code all have their work captured through the CLI. See Supported AI Agents and Capture.

Next steps

• Jolli Memory - install, sign in, and your first Memory
• Use Your Memory from Any AI Agent (MCP) - the MCP tools
• Recall vs Search - when to use which
• Reference - every CLI command and configuration key
• Supported AI Agents and Capture - how each agent is captured
• Troubleshooting and FAQ - when something is not working