Skip to Content
Jolli MemoryJolli Memory in CI and Automation

Last Updated: 7/23/2026

Jolli Memory in CI and Automation

Jolli Memory runs headless. Everything you do interactively - install, sign in, enable, commit, view - also works from a script or a CI job with no editor and no browser. This page covers the pieces that are specific to unattended runs: non-interactive auth, the one timing gotcha to know about, and how commits with no AI transcript are handled.

Install and authenticate without a browser

Install the CLI (Node 22.5+):

npm install -g @jolli.ai/cli

Summaries need an LLM credential. In CI, provide one of:

  • Your own Anthropic key (simplest): set ANTHROPIC_API_KEY in the job environment. Memory calls Anthropic directly, no Jolli account required.
  • A Jolli API key: jolli configure --set jolliApiKey=sk-jol-.... This one key covers both summary generation (via the Jolli LLM proxy) and publishing memories to a team Space (below) - use it if you want CI memories to reach your team. Create the key at Settings → Jolli Memory → Create Key.

Heads up: JOLLI_AUTH_TOKEN (the OAuth token) only sets your account identity, it does not provide a summary-generation path. A CI run needs ANTHROPIC_API_KEY or jolliApiKey, not just JOLLI_AUTH_TOKEN.

Enable non-interactively

jolli enable -y

-y skips the interactive prompts. Run it from the repo root; jolli status confirms the result.

Wait for summaries to finish (the important part)

A commit returns instantly and the summary is generated by a detached background worker. That is exactly what you want interactively, but in CI it is a trap: if the job commits and then exits, the runner can tear the worker down before the summary is written.

After your commit, block until the queue drains:

jolli queue-status --wait --timeout 120

--wait blocks until every pending summary is generated or the timeout (default 120 seconds) elapses. Add --format json for a machine-readable result you can gate on.

Persist the memories off the runner

On a stateless CI runner the memory is written locally (the git orphan branch and the Memory Bank folder) and then thrown away when the job ends. To keep CI-generated reasoning, publish the branch’s memories to a team Jolli Space - that is the intended way to get them off the runner and in front of your team:

jolli spaces                          # find your Space id or slug
jolli push --space <space-id-or-slug>

Run push after queue-status --wait so the summaries exist first. push binds the repo to the Space on first use, and because the binding is stored server-side by your repo’s URL, later CI runs just push - no re-bind. Publishing requires a Jolli API key (BYOK-only setups cannot share); the same key you use for generation covers it.

(If you run on a persistent or self-hosted runner and only want memories stored with the repo, you can skip this - the local orphan branch survives there.)

Commits with no AI transcript

CI commits usually have no AI coding session behind them. That is fine: when there is no transcript, Memory generates a diff-only summary from the git diff alone, as long as a credential is available. You still get a structured Memory for the commit, just built from the change itself rather than a conversation.

Generating Memories in batch

To create Memories for commits made before Jolli was enabled, or to fill gaps, use backfill. It runs synchronously in-process (no detached worker), so no queue-status wait is needed:

jolli backfill --last 50      # the most recent 50 commits (default 20)
jolli backfill --all          # every commit missing a Memory
jolli backfill --dry-run      # report what would be generated, no LLM calls

Backfill attributes on-disk Claude Code transcripts; commits without an attributable transcript get a diff-only summary. --min-confidence <high|medium|low> controls how loosely a transcript is matched to a commit.

Environment variables

VariableWhat it does
ANTHROPIC_API_KEYBYOK LLM credential; Memory calls Anthropic directly.
JOLLI_AUTH_TOKENOAuth-token override for account identity (not a summary credential).
JOLLI_URLOverride the Jolli server origin (allowlisted, HTTPS-only).
JOLLI_NO_PLUGINSSet to 1 to disable plugin discovery (the Site and Space commands).
XDG_DATA_HOMEBase dir for OpenCode’s session database. Default ~/.local/share.
DO_NOT_TRACKSet to any non-empty value other than 0 to opt out of usage telemetry.

(ANTHROPIC_BASE_URL is honored by the Anthropic SDK itself, not by Jolli, so treat it as SDK-level rather than a documented Jolli setting.)

Other automation notes

  • Target a specific repo with --cwd <dir> on any command (enable, status, view, recall, backfill, and the rest), instead of relying on the current directory.
  • jolli clean refuses to delete in a non-interactive shell unless you pass -y/--yes; use --dry-run first to preview.

Example: GitHub Actions

This example generates memories in CI and publishes them to a team Space, using one Jolli API key for both:

- name: Install Jolli Memory
  run: npm install -g @jolli.ai/cli
 
- name: Configure and enable
  run: |
    jolli configure --set jolliApiKey=${{ secrets.JOLLI_API_KEY }}
    jolli enable -y
 
# ... your steps that commit to the repo ...
 
- name: Wait for memories, then publish to the team Space
  run: |
    jolli queue-status --wait --timeout 120
    jolli push --space ${{ vars.JOLLI_SPACE_ID }}

The jolli push step is what persists the reasoning: on a stateless runner, without it the memory is discarded when the job ends. (For generation only, on a persistent runner, an ANTHROPIC_API_KEY in the job environment is enough and you can drop the push step.)

Memory Bank and SyncReference