Last Updated: 8/19/2026

Jolli Memory in CI and Automation

Overview

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.

Prerequisites

• Node 22.13 or later on the runner.
• A git repository, checked out with enough history for the commit you are recording.
• An LLM credential that can generate summaries: ANTHROPIC_API_KEY or a Jolli API key. JOLLI_AUTH_TOKEN sets your account identity only and does not generate summaries - a job with just that will run and produce nothing.
• To push memories to a Space, a Jolli API key specifically.

Install and authenticate without a browser

Install the CLI:

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

(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.)

Inspect Workflow runs from a script

If you use Jolli Workflows on a git-backed Space, the jolli workflow plugin reports on runs in a form scripts and agents can consume. Install it alongside the CLI:

npm i -g @jolli.ai/cli @jolli.ai/workflow-cli @jolli.ai/space-cli

space-cli is only needed for jolli workflow local-run, which calls jolli space clones behind the scenes - installing all three up front avoids a failure on the first command.

Every subcommand prints JSON on stdout, so you can pipe it straight into jq:

# Which Workflows can run locally on this machine right now?
jolli workflow local-run
 
# A Workflow's run history, newest first
jolli workflow runs <workflowId>
 
# Block until a run reaches a final state, then print its report
jolli workflow run-status <runId>

run-status is the one to reach for in a pipeline: it waits for the run to finish rather than returning immediately, so a script can act on the outcome. It needs a Jolli sign-in, and it only sees git-backed Spaces cloned on this machine. None of the three starts a run.

For the full command list, see Reference.

Other automation notes

• Target a specific repo with --cwd <dir> instead of relying on the current directory. Most repo-scoped commands take it (enable, disable, status, view, recall, backfill, doctor, dashboard, compile and more). The account-level commands do not: jolli configure and jolli auth have no --cwd, because they read and write machine-wide configuration rather than a repository.
• 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.)

Next steps

• Getting Started with Jolli Memory - install, sign in, and your first Memory.
• Reference - every config key, command, and flag.
• Supported AI Agents and Capture - how sessions are captured, and the diff-only fallback.