# Jolli Support > Jolli is a self-updating knowledge layer: memory and context for developers, agents, and users. These docs cover Jolli Memory (CLI, MCP, editor and Claude Code plugins), Spaces, and Sites. --- # Jolli Sites Source: https://docs.jolli.ai/jolli-sites ## Overview A Site is a published documentation website built from a Space. One Space can power more than one Site (a public one and an internal-only one drawing from the same Articles, for example). You don't write content on a Site. Writing happens in a [Space](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces); a Site is the published output. ## Prerequisites - An existing Space with content to publish. - The **`sites.edit`** permission, which the Owner and Admin roles carry. The built-in **Member** role does not, so a Member cannot create or publish a Site - ask an Owner or Admin. - For a custom domain, access to your registrar's DNS records. ## Create a Site From the sidebar, click **+** next to **Sites**. The wizard has four steps (three for Spaces backed by a git repo, which take their branding from the repo). ### Basics - **Display Name** - the human-readable title shown in the browser tab and the Site header. Example: `Orbit SDK Docs`. - **Site Name** - Lowercase letters, digits, and hyphens; minimum 3 characters. Becomes part of the URL. - **Subdomain** - optional; must start and end with a letter or digit, no consecutive hyphens (3–63 characters). Blank means Jolli generates one from the Site Name. A live URL preview (`docs-account.jolli.site`) updates as you type. You can point your own domain at the Site afterward. ### Content Pick the Space the Site pulls Articles from. What happens next depends on how that Space is backed. **A regular Space.** You choose which Articles go on the Site, not just which Space. **Include all articles** is the simple path: leave it on and every published Article is included, now and as you add more. Turn it off and you get a checkbox tree of the Space's folders and Articles, with **Select all**, **Deselect all**, and a search box; ticking a folder ticks everything under it. **Next** stays disabled until either include-all is on or you have picked at least one Article. However you select them, the Space's folder structure becomes the structure of the Site. **A Space backed by a git repository.** There is nothing to select - every Article comes across - so instead Jolli reads the repository's `site.json` and tells you what it found: - **site.json looks good** - it summarizes the title, theme pack, header items, and whether a footer is defined, then lets you continue. - **Using folder structure for navigation** - no `site.json` in the repository. Jolli generates the sidebar from your folders and you can continue; add the file later to take control of it. - **site.json has errors** or **Couldn't read your repo** - these block **Next**. Fix the file, or the repository connection, and try again. ### Branding Preset themes help you decide the base look and feel of your Site. Once selected, you can override colors, logos, fonts, header links, and footer on the **Branding** tab after creation. ### Access | Tier | Who can read | | --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | **Public** | Anyone with the link; search engines can index it. | | **Restricted to Jolli users** | Signed-in members of your organization only. | | **Restricted to ALL Jolli users** | Any signed-in Jolli user, even outside your organization. Gated by an organization capability - if it's not enabled, this option doesn't appear. | Restricted (auth-required) Sites show a sign-in banner on every page, controlled by a toggle that is on by default. Public Sites have no sign-in banner. Click **Create Site**. Jolli builds the initial version, provisions hosting, and deploys. Status moves from **Publishing...** to **Up to date**; click the external-link icon to open it. ## The Site detail view Opening a Site gives you two views in the left nav, **Content** and **Branding**, grouped under a **Site** heading. Content opens first. **Settings** is the button at the foot of that nav and opens a separate page holding the Site's information and statistics, the domain, access, schedule, and Danger Zone. Branding is covered below. ### Changing what the Site includes The **Content** tab is where you revisit the choices you made in the wizard's Content step. It has two parts. **Articles.** The same picker as the wizard: **Include all articles**, or an explicit selection with search and select-all. Changes here are not live until you click **Save Selection** - the button reads **No changes** until you have made one. Removing an Article from the selection takes it off the Site on the next publish; it stays in the Space untouched. **Space.** You can point the Site at a different Space from here. Jolli warns first that changing the Space will clear your current Article selection, which it will - the selection belongs to the old Space's Articles and does not carry over. On a git-backed Site the tab is there but has no controls. It shows a **Managed by site.json** notice naming the connected repository and branch, because the repository decides both what is included and how it is arranged. ## Theme packs The **Branding** tab leads with a theme pack - the overall look and layout your Site is built on. Pick one from the preview cards, then fine-tune colors, typography, logo, and navigation in the sections below. Two built-in packs ship today - **Forge** and **Atlas** - and more may be available from the theme registry. Git-backed Sites take their branding from the connected repo, so the Branding tab is read-only for them. ### Upgrading from Classic (one-way) Older Sites may still be on the **Classic** pack, which carries extra Layout and Navigation controls. Selecting a built-in pack (Forge or Atlas) on a Classic Site is a one-way upgrade: - A confirmation dialog shows which pack you're switching to before anything changes. - Confirming restyles the Site and drops the Classic-only Layout and Navigation settings. **There is no way back to Classic** once you upgrade. - A Classic Site can't jump straight to a registry theme - upgrade to a built-in pack first, then pick a registry theme from the normal picker. Branding changes, including a pack upgrade, take effect on the next publish. ## site.json, for Sites backed by a repository When a Site's Space is backed by a git repository, a file named `site.json` at the root of your docs folder controls the Site's title, navigation, and look. This is why the **Branding** tab is read-only for those Sites: the repository is the source of truth, so you change branding by editing the file and publishing, not in the app. A published Site needs a title, a theme, and navigation. A description is optional, and worth setting anyway: ```json { "title": "Orbit SDK Docs", "description": "Guides and API reference for the Orbit SDK.", "theme": { "pack": "forge" }, "navigation": [ { "group": "Get started", "content": [ { "article": "Introduction", "href": "/introduction" }, { "article": "Install", "href": "/install" } ] }, { "article": "Authentication", "href": "/api/auth" } ] } ``` Note the shape of `navigation`: a group's `content` is a list of entries, not a path. Each entry is an `article` with an `href`. The fields you will use most often: - **`title`** and **`description`** - shown in the browser tab and the header, and used for the `llms.txt` heading. - **`theme`** - the theme pack and its overrides: `pack`, `primaryColor`, `logoUrl`, `favicon`, `defaultTheme`, `fontFamily`. - **`navigation`** - the sidebar and any navbar tabs. Entries are pages, groups, or articles. - **`header`** and **`footer`** - navbar items and dropdowns, and the footer's copyright, link columns, and social links. ### The two places site.json is read are not identical The same filename is used by the hosted Site and by the `jolli site` commands you run on your own machine, and they do not accept exactly the same file. A file that builds locally can be rejected when you publish, and the reverse. The differences worth knowing: - The hosted Site **requires** both `theme` and `navigation`. A local build treats them as optional. - Neither one checks the theme pack name when it reads the file: both accept any non-empty string, and a pack that does not exist fails later, when the Site is built, rather than when `site.json` is parsed. So a typo in `pack` surfaces as a build error, not a validation error. **Classic** is not selectable on either side; a Classic Site upgrades through the app first. - The hosted Site is strict about the contents of `theme`, `header`, and `footer`: a misspelled field inside one of them makes the whole file invalid. A local build ignores fields it does not recognize, so the same typo silently does nothing. ### A rejected site.json does not fail the build This is the part worth knowing before you go looking for an error that isn't there. When the hosted Site can't validate your `site.json`, **it publishes anyway.** The file is discarded whole, navigation is regenerated from your folder structure, and the title falls back to the Space's name. The Site's status reads **Up to date**, because from the build's point of view nothing failed. What you get instead of an error is a single warning line in the build log, naming the field that failed and saying navigation came from the directory structure. A missing `site.json` behaves the same way, with an informational line rather than a warning. So the symptom to recognize is not a build failure. It's a Site that published successfully with the wrong navigation, the wrong title, and none of your branding. If that happens, open the build log and read the warning line - it names the field. One typo inside `theme` is enough to cost you the entire file. The creation wizard is the one place that does stop you: it checks `site.json` before letting you continue, and a file it can't read or can't validate blocks the **Next** button there. ## Tweaking branding after creation The Site detail view's **Branding** tab handles post-create edits. Changes apply on the next publish. - **Default theme** - Light, Dark, or System. - **Typography** - The font style that your Site uses - **Accent color** - pick from preset swatches, a color picker, or a hex value. Drives headings, links, and primary actions. - **Logo URL** - PNG, SVG, or WebP. Around 400px wide for retina. - **Favicon URL** - ICO, PNG, or SVG; 32×32 or 16×16. Logo and favicon are URL-based, not uploaded - you provide a publicly accessible URL Jolli fetches at build time. ### Header navigation Add up to 6 top-level header items beyond the auto-generated content tree. Each item is either: - A **Link** - label + URL. - A **Dropdown** - label + up to 8 child links. Use it for things that don't belong in the navigation tree itself - Pricing, Changelog, your main marketing site, an external GitHub link. ### Footer - **Copyright** line - up to 200 characters. - Up to **4 columns**, each with a title and up to **10 links**. Group resource links however you like. - **Social links** - GitHub, Twitter/X, Discord, LinkedIn, YouTube, and Bluesky. Each renders in the footer. ## Custom domain Every Site gets a `sitename-account.jolli.site` URL by default. Point your own domain at it under **Site Settings → Custom Domain**. Each site supports one custom domain. You can add a subdomain (`docs.yourdomain.com`) or an apex (`yourdomain.com`). Each needs a different DNS record type. ### Subdomain - CNAME | Field | Value | | --------- | --------------------------------------------------------------- | | **Type** | CNAME | | **Host** | the subdomain part (`docs`, if you added `docs.yourdomain.com`) | | **Value** | the value Jolli displays on the Domain tab | Field names vary by provider - Host may be called "Name," Value may be called "Target." ### Apex - A | Field | Value | | --------- | --------------------------------------- | | **Type** | A | | **Host** | `@` (or leave blank) | | **Value** | the IP Jolli displays on the Domain tab | Apex domains don't support CNAME at the top level. If your DNS provider supports ALIAS, ANAME, or flattened CNAME at the apex (Cloudflare and a few others), follow their guidance. Leave TTL at the provider default. ### Verify ownership (TXT) Some domains need a second record to prove ownership - usually an apex domain, or one already in use on the hosting side. When Jolli shows a **Verify domain ownership** step with a **TXT** record, add that record too, alongside the CNAME or A record above. If no TXT step appears, none is needed. ### Verification The domain enters the list as **Awaiting DNS**. While any domain is pending, Jolli auto-checks the DNS record. When the record matches, the status moves to **Connected**. If it doesn't match, the status shows **Check DNS** - usually a wrong record type, an existing conflicting record, or a DNS-provider quirk (Cloudflare's proxy mode, for instance, can change CNAME resolution). Click **Verify** to force an immediate re-check. DNS propagation usually takes 30 minutes or less; rarely several hours. To remove a domain, find it in the list and click **Remove**. Jolli stops serving the Site at that domain immediately. Re-adding requires re-verifying DNS. A domain points at exactly one Site. Use subdomains (`docs.`, `help.`) to host multiple Sites under the same root. ## Publishing Each Site shows a status indicator: - **Up to date** - live Site matches current Articles. - **Publishing...** - rebuild in progress. - **Pending Changes** - unpublished edits in the Space; click **Publish** to catch up. The panel names what is waiting, which includes an edited **Site Summary** and out-of-date **Search Engine Files** as well as article changes. - **Build error** - last build failed; click for logs. ### Manual publish Click **Publish** in the Site header. Jolli rebuilds from the current Space state and deploys. While a site is building, the indicator shows a live progress percentage that updates as the build proceeds. If you started it by mistake, click **Cancel Build** to stop the build. ### Auto-publish schedule Under **Site Settings → Auto-Publish Schedule**, tick **Enable auto-publish**, set the interval and time of day on the **Every ... day(s) at ...** row, and **Save**. A **Times shown in ...** note names the timezone, read-only from your profile. Scheduled builds run on the cadence you set, regardless of whether anything changed - each run regenerates and republishes the Site. Pick a low-traffic hour and a sensible interval so you aren't rebuilding more than you need. ### Publish on branch update For a Site whose Space is backed by a git repository, **Site Settings → Publish on Branch Update** republishes the Site automatically whenever its watched branch is updated. Turn on **Enable publish on branch update**, and the panel shows which branch is being watched. Unlike the schedule above, this fires on a push rather than on a clock. ### Source-driven publishing If the Site's Space has connected Sources, [Gap Analysis](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) can trigger rebuilds when tracked code changes. A push lands → Gap Analysis proposes a Changeset → auto-apply (if on) applies it → **Pending Changes** appears → the next auto-publish or manual click rebuilds. Auto-apply is **on** for a new shared Space, whose repository Jolli manages, and **off** for a Space you bound to your own repository. See [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent). ### Build errors Common causes of build failures include: - **Malformed Markdown** - usually an unclosed code fence or HTML tag. The build log names the article and line. - **Invalid OpenAPI spec** - JSON or YAML parses but is missing required fields (`openapi`/`swagger`, `info.title`, `info.version`, `paths`). (Both JSON and YAML are accepted; no conversion needed.) - **Broken image references** - an image URL in an article isn't reachable from the build environment. (A Space with no published Articles is *not* a build error - it builds a placeholder page.) Every failure produces a plain-English **What Happened** summary plus the last 500 lines of raw build logs. Open the build error from the changes indicator at the top of the Site detail view. ## AI discovery (llms.txt) Every published Site automatically generates two plain-text files at its root for AI clients (Claude, Cursor, ChatGPT, and others) to ingest: - **`/llms.txt`** - a titled, sectioned index of the Site's pages, each with its link and a short description. Sections follow your navigation and folder structure; OpenAPI specs are grouped under an **API Reference** section. - **`/llms-full.txt`** - the full prose corpus: every page's Markdown body concatenated into one document. Both are written on every publish - for git-backed and managed Sites alike - and every page advertises them in its HTML `` (``) so AI clients can discover them automatically. Page descriptions come from each Article's frontmatter `description:`, falling back to its first paragraph. To ship your own version of either file, commit an `llms.txt` or `llms-full.txt` at your docs root - Jolli passes an author-provided file through untouched. A very large `llms-full.txt` (roughly 2 MB or more) still builds but logs a size warning, since a big corpus can slow AI ingestion. On a Restricted Site, both files sit behind the same sign-in gate as the rest of the Site. `/llms.txt` is written for an agent arriving with no other context, so a few things are deliberate: - **Links are absolute.** Page links and the `Source:` line under each entry carry the full URL, so an agent that reads the file on its own can follow them without knowing where it came from. - **Cross-references between your articles resolve to real URLs.** A link written as a `jrn:` reference in one article points at the other article's published page rather than at an internal identifier. - **Sections follow your navigation.** Headings come out in the order your Site's navigation defines, instead of alphabetically by slug, and each page contributes a single heading. ### Give your Site a summary **Site Settings → Site Description** takes a one-line summary of what the Site covers. It opens `/llms.txt`, so an agent knows what the Site is before it reads a single page. The field's own help text says it plainly: published to `/llms.txt` on the next publish. Editing the summary does not change the live Site on its own - it shows up under **Pending Changes** as **Site Summary** until you publish. ## robots.txt and sitemap.xml Every published Site also serves the two files search engines look for. - **`/robots.txt`** is always written. On an open Site it allows crawling, points at `/sitemap.xml` once the Site has a web address, and names `/llms.txt` in a comment so an agent fetching the first file finds the second. - **`/sitemap.xml`** lists every page of the Site, and is written once the Site has a canonical web address. Before a domain is attached there is no address to build absolute links from, so no sitemap is produced - attach a domain and republish. A Site behind a sign-in is treated differently: `robots.txt` carries a blanket `Disallow: /`, no sitemap is written, and `/llms.txt` is not advertised. Pointing crawlers at the full contents of a gated Site would defeat the gate. A very large sitemap (above 50,000 URLs) still builds, with a warning in the build log - search engines may ignore the overflow. If a Site was published before these files existed, or published before its web address was assigned, that shows up under **Pending Changes** as **Search Engine Files**. Republishing regenerates them. ## Ask the Agent to manage your Sites The Jolli Agent can do most Site work for you from a conversation: create a Site, publish or republish one, change its display name, source Space, or article selection, list your Sites, check a build's progress, and crawl an existing public docs site to import its pages into a Space. Ask in plain language, for example "publish the docs site" or "import the pages from docs.example.com". Creating and editing Sites this way needs the same permission as doing it by hand. ## Site search Every published Site ships a full-text search index, built at publish time from the pages you selected. No setup and no third-party service. ## Browse and edit the backing repository On a git-backed Site, **Repository Contents** shows the files behind it. You can pick a **Branch**, see when it was **Last synced**, and run **Sync Now**. It is a working file manager, not just a viewer. **Files and folders.** Right-click a folder for **New Folder**, **Rename Folder**, and **Delete Folder** - deleting one takes everything inside it, and Jolli says so when the folder isn't empty. A file's menu has **Move to...**, which asks for a destination folder. **New File** is restricted by location: at the root you may only add Nextra config files and pick from a list of the ones you don't already have, and inside a content folder you add a `_meta` file, one per folder. Files Jolli generates are marked **Read only - managed by Jolli**. **Editing is staged, not immediate.** Changing a file marks it *Change staged - click Save to commit*. Nothing reaches the repository until you press **Save**; **Discard** throws the edit away. Because a save is a commit, treat it as one. **Syntax errors block the save.** Jolli checks the file as you type and lists what it finds in an **Issues** panel, counting errors and warnings, including two consistency checks against `_meta.ts`: an entry with no matching Article file, and an Article file not listed in `_meta.ts`. While an error stands, the save button reads **Cannot save: fix syntax errors first**, and Jolli also stops you switching files until it's resolved. **Format** tidies the file up. ## Custom scripts and styles To add analytics, a chat widget, or CSS that the branding settings do not cover, commit `.js` or `.css` files to a `.jolli/scripts` folder in the connected repository. Jolli injects them into every page on the next publish. Up to 20 files, each up to 64 KB. ## Delete a Site Deleting a Site is permanent. It lives in a **Danger Zone** at the bottom of **Site Settings**, available once the Site has finished its first build (its status is live or shows a build error). - Under **Delete this site**, click **Delete**. An inline confirmation appears with a warning that the action can't be undone. - Click **Delete Permanently** to confirm, or cancel to back out. While the delete runs, the button shows a deleting state. Deleting a Site removes the published website and stops serving it. The [Space](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) it was built from - and all its Articles - are untouched; you can build a new Site from the same Space later. ## Next steps - [Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) - where the content actually lives. - [Editing & Organizing](https://docs.jolli.ai/jolli-spaces/editing) - the writing surface. - [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) - the AI agent and review flow that produces what gets published. --- # Settings Source: https://docs.jolli.ai/settings ## Overview Workspace and account settings live under the **Settings** menu. This page covers the areas that matter day-to-day: your profile and preferences, the people in the organization, the roles that govern what they can do, the apps you have connected to your account, and - for developers - API keys and the MCP surface. ## Prerequisites - **Profile, Preferences, Connected apps and personal API keys need no special role.** - **Workspace and Users need Owner or Admin.** Changing someone's role is Owner-only, as is resetting the Getting Started guide. - Custom roles need a paid organization. ## Profile Personal account settings at **Settings → Profile**. - **Name** - edit freely. Shown in the Users list. - **Email** - read-only. Contact support to change it; the change affects sign-in and outstanding invites. - **Password** - set or change it (if you sign in with a password rather than OAuth). - **Timezone** - used where the app schedules things for you, such as auto-publish times. ### Sessions A list of browsers and devices currently signed into your account. Each row shows device, approximate location, and last-active time. - **Logout this device** - ends a specific session. - **Logout other devices** - ends every session except the one you're using. - **Logout from all devices** - ends every session, including the one you're using. A confirmation dialog appears first. Sessions also expire when your Remember Me token does (30 days), or when you reset your password - the reset ends your other sessions as a security precaution. ### Getting Started guide Owners can **Reset Getting Started Guide** here. It brings back the Getting Started conversation so you can walk through setup again; open the Jolli Agent afterward to see it. ## Preferences App preferences at **Settings → Preferences**, grouped into four sections. ### Appearance - **Theme** - Light or Dark for the whole web app. Sites you publish have their own theme controls, independent of this. - **Language** - your preferred language for the interface. ### Interface - **Sidebar default state** - whether the sidebar starts **Expanded** or **Collapsed**. - **Chat panel width** - the default width of the chat panel, from 300 to 800 pixels. ### Articles - **Default draft filter** - which drafts show by default: **All**, **My New Drafts**, or **Shared With Me**. - **Show AI tool details** - show detailed information about AI tool usage in article drafts. ### Agent How the Jolli Agent starts a conversation, each overridable per-conversation: - **Default conversation mode** - Plan, Exec, or Auto. See [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent). - **Allow auto mode** - makes Auto selectable in the Jolli Agent; Auto auto-approves non-destructive agent actions. - **Show extended thinking** - show the AI's thinking blocks in Agent conversations. ## Connected apps **Settings → Connected apps** lists the agents and applications you have authorized to reach a workspace on your behalf - the ones that connected by signing in through the browser rather than with an API key. Everyone sees this page; these are your own credentials, not the organization's, so there is no role requirement and no admin equivalent. Each row shows the **Application**, the **Workspace** it was granted, its **Access**, when it was **Connected**, and when it was **Last used**. Access is spelled out in plain terms. Read it carefully, because it covers more than reading: - "Read content in this workspace, and start or cancel Workflow runs that can add or change content in it." - "Save new memories into this workspace", where that was granted. An agent listed here can therefore change what is in the workspace, not just look at it: starting a Workflow run is how content gets added or rewritten. Browser approval can grant both lines at once, so treat this page as the record of what each application is actually able to do. The consent screen you saw when you first authorized the application words the same permission slightly differently, because it is describing a workspace you are about to pick rather than one already chosen: "Read content in the workspace you choose below, and start or cancel Workflow runs that can add or change content there." **Disconnect** on the row is how you cut an agent off. Jolli confirms first, then the application loses access on its very next request; reconnecting means authorizing it again from the application itself. This is the place to come when an agent is retired, a laptop is lost, or a tool has more access than you meant to give it. Grants and API keys are two separate ways in: deleting one does not touch the other. ## Workspace (Owner, Admin roles) **Settings → Workspace** is where you rename your workspace - the name shown to everyone in the organization. Only Owners and Admins see this page. - **Workspace name** - edit it and click **Save** (the button reads **Rename** until you change the value). Up to 255 characters. This sets the organization's display name; the unique slug it was created with doesn't change. ## Users (Owner, Admin roles) The Users page is at **Settings → Users**. ### Inviting your team The Users page leads with an **Invite your team** card offering two paths - **Invite a colleague** (a single person) and **Import a CSV** (bulk). Both open the same **Invite your team** dialog, which has an **Invite someone** tab and an **Import CSV** tab. (For the organization Owner, a dismissible **Invite your team** banner also appears atop the default shared space.) The first-run **Set up Jolli for your team** page carries its own **Invite your team** card, which opens the same dialog. The cards on that page are shown only to someone who can invite people - see the permission matrix below. Anyone else lands straight on the install commands, with no cards above them and nothing to collapse. On the **Invite someone** tab, enter an email, pick a role (default Member), and send. The invitee gets an email from Jolli; if they already have a Jolli account the link adds them to this organization, otherwise it takes them through signup first. Invites are per-email - if someone changes their address, they need a fresh invite. An invitation link is good for **7 days**. After that it stops working and the row shows as expired on the **Pending** tab; use **Resend** to send a fresh one. To withdraw an invitation instead, use **Cancel Invitation** on the row - Jolli asks you to confirm the address, then the invite stops working and the row leaves the list. Cancel and re-invite is the way to correct a mistyped address or change someone's role before they accept. The **Import CSV** tab onboards a whole team at once. Each valid row becomes a standard invitation, identical to inviting one person at a time. The file needs an `email` column, plus optional `name` and `role` columns: ``` email,name,role jane@acme.com,Jane Doe,admin sam@acme.com,Sam Lee, ``` - Up to **100 rows** per file. Larger files are rejected - split them or send more than one. - Rows with a blank `role` use the **default role** you pick in the dialog (Member unless you change it). - A preview flags each row before you send: **Ready**, invalid email, unknown role, or duplicate. Only Ready rows are invited. - After sending, each row reports its outcome - invited, already a member, rate-limited, or failed. ### The three tabs The Users list is split into **Active**, **Pending** and **Archived**. - **Active** - everyone currently in the organization. - **Pending** - invitations sent and not yet accepted, with when they were invited, by whom, and when they expire. - **Archived** - people who have been removed, showing **Removed At**, **Removed By** and **Reason**. This is where to look when someone's account has stopped working and you need to know who removed them and when. ### Managing Each row in the Users list has a three-dot menu: - **Edit** - opens a dialog where you can rename the user, and where an Owner can also change their role to any built-in or custom role. Changing a role needs role-management permission, which Admins do not have by default, so an Admin sees the dialog but can only rename. - **Deactivate** / **Activate** - Deactivate revokes their tokens immediately; their data and assignments stay intact. Activate restores access. - **Delete** - permanent. Non-personal **Spaces** owned by the user transfer to **you** (the admin performing the deletion); personal Spaces are soft-deleted. Articles and Changesets keep their original author reference (which now points to an archived user); they are not reassigned. ## Roles Every user has a role. Roles determine what they can see and do - which Articles they can edit, whether they can manage Sources, whether they can invite teammates, and so on. Jolli ships with three built-in roles. Paid organizations can also create custom roles. ### Built-in roles - **Owner** - full access. Exactly one per organization. Can promote, demote, transfer ownership, or delete the organization. - **Admin** - broad day-to-day management. Can manage users, Sources, Sites, and content. Can't transfer ownership or delete the organization. Roles are Owner-only by default, so an Admin does not see the **Roles** page at all and can't change anyone's role. - **Member** - the everyday contributor. Can view and edit Articles in the Spaces they have access to. They cannot manage users, roles, integrations, or sites by default. Use a custom role if you need a more restricted contributor. ### The permission matrix Permissions break into categories, each with a **View** and an **Edit** level. | Category | View | Edit | | ---------------- | ------------------------------------------- | ---------------------------------------------------------- | | **Articles** | Read Articles | Create, edit, delete; comment moderation | | **Spaces** | See Spaces and structure | Create, rename, delete Spaces | | **Integrations** | See connected Sources | Connect, configure, disconnect | | **Sites** | See published Sites | Create, customize, publish | | **Users** | See organization users | Invite, deactivate, delete | | **Roles** | See roles | Create, edit, delete custom roles | | **Jolli Memory** | See API keys and Jolli Memory configuration | Create / disable / delete API keys, configure push targets | The Jolli Memory category carries a third permission that is neither View nor Edit: **View Team Memory Activity**, which governs the **Team Dashboard** group in [The Web Dashboard](https://docs.jolli.ai/jolli-memory/the-web-dashboard) - other members' sessions, spend and commits. It is separate from View because seeing the organization's API keys and seeing colleagues' work are different questions. **Owner and Admin have it. Member does not.** Since built-in roles cannot be edited, the way to give it to someone is a custom role that includes it. An additional **Workflows** category appears if Workflows is enabled for your organization. It governs the organization-wide workflow run defaults at **Settings → Workflow Defaults**: View sees them, Edit changes them and any per-workflow override. Running, pausing, and cancelling a Workflow is controlled separately, by your role in the Space the Workflow targets - see [Workflows](https://docs.jolli.ai/jolli-spaces/workflows). Some permissions have cross-category dependencies - for example, Roles (Edit) requires Users (Edit) - and enabling any Edit level automatically includes its View. ### Custom roles To create one: 1. **Settings → Roles → Clone** next to whichever built-in role is closest. 2. Rename, toggle permissions, save. 3. Assign from the Users page or the invite dialog. Editing a custom role takes effect immediately for assigned users (they may need to sign out and back in to pick up new permissions). Built-in roles can't be edited or deleted. ### Ownership transfer Always exactly one Owner on an account. To change an owner on an account, contact [support@jolli.ai](mailto:support@jolli.ai). ## Developer ### API keys API keys let the Jolli CLI and external tools act on your behalf. Keys are scoped to what their creator can access. There are two places to manage them, and which one you want depends on whose keys they are: - **Settings → Jolli Memory**, under **Personal**, holds your own keys. Anyone can use this page; no special permission is needed. You can hold up to **10** keys at a time, and creating an eleventh is refused until you delete one. - **Settings → Jolli Memory Manager**, under **Account**, lists the keys across the organization. This one needs Jolli Memory permission, and it is where an admin revokes a key belonging to someone else. On either page you can create a key, disable it, or delete it. Disabling is reversible; deleting is not. A key stops working immediately if the person who created it is deactivated, and starts working again if they are reactivated. **What a key is allowed to do is set organization-wide, not per key.** There is no per-key scope list yet, so when a capability is enabled for the organization, every key already in existence gains it, with nothing reissued and no restart needed. That is how the session-statistics upload behaves: it is enabled by default, so any key your organization holds can upload session statistics, including keys minted for CI a long time ago. If you would rather it could not, an admin can turn the session sync off for the organization, and individual machines can turn it off for themselves. See [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). ### Connect an external AI client (MCP) Jolli exposes an **MCP** (Model Context Protocol) surface so an external AI client can read your documentation using one of your organization's API keys. Most of it reads; a few tools write or act, and those are called out where they appear. It's on by default; an organization admin can turn it off, which makes the whole surface unavailable. The tools an authorized client can call: | Tool | What it does | | ---- | ------------ | | `list_remote_spaces` | List the Spaces the key's owner can access. | | `search_remote_articles` | Search Article titles **and body content** across accessible Spaces. Each result carries a link you can open, a plain-text snippet of the match, and a relevance score. | | `get_remote_article_content` | Fetch one published Article's content by its JRN. | - Access is scoped to what the key's creator can view. Personal Spaces and deleted Articles are never returned; only published content is served. These three documentation tools also leave Jolli Memory Spaces out. - Create an API key under **Settings → Jolli Memory**. While MCP is enabled, every API key can reach this surface automatically - there's no separate scope to toggle. - Point your client at your organization's Jolli API base (the `/api/mcp` endpoints) and authenticate with the API key. ### Let a hosted agent read your memory Alongside the documentation tools above, an authorized client can read your organization's **Jolli Memory**: | Tool | What it does | | ---- | ------------ | | `search_remote_memory` | Search your organization's memory across every memory Space the key's creator can access. | | `get_remote_memory_content` | Fetch one memory document's content by its JRN. | | `create_remote_memory` | Create a new memory - a decision, a summary, or a note - in a memory Space. | These are the mirror image of the documentation tools: they reach memory Spaces and nothing else, while the documentation tools continue to exclude memory. `create_remote_memory` is the only one that writes. It targets your organization's default memory Space unless the caller names another, and it fails rather than creating a Space if there is no default and none was named. Documentation and personal Spaces are refused. What decides whether a write is allowed is the per-space contribution permission of whoever created the key, so an agent can never write somewhere its key's creator could not. An agent that cannot run a local process connects over the web, at **`https://jolli.ai/mcp`**, as a Streamable HTTP MCP server. Turning MCP off for the organization turns this off with it. **Hosted assistant endpoint** on this page shows that address with a button to copy it, so you do not have to transcribe it. It is the only address the endpoint accepts: a connection arriving on a workspace subdomain or a custom domain is turned away, with a message naming this one instead. Agents connect either by signing in through the browser, where the person approving picks which organization the agent reaches, or with an API key using `Authorization: Bearer sk-jol-...`, where the key itself determines the workspace. Either way there is no workspace name in the URL. The six tools above are the documentation and memory ones. The hosted endpoint carries more: reads over a connected repository, and discovery, status and run control for Workflows. [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp) lists all twenty-three and covers setup end to end. If you are deciding what an agent will be able to do once you authorize it, read that list rather than this one. This is all distinct from the Jolli Memory MCP server your local coding agent runs - that one is a process on your own machine reading the memories stored with your repo, while this surface is hosted by Jolli. ## Related - [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space) - per-Space members and roles, distinct from the organization roles above. - [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) - what the AI mode defaults control. - [Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - the API keys and MCP settings above power Jolli Memory. --- # Welcome to Jolli Source: https://docs.jolli.ai/welcome-to-jolli Jolli keeps your documentation, reasoning, and shared understanding up to date from your sources, across three layers that work together: Jolli Memory, Jolli Spaces, and Jolli Sites. ![jolli-blackbg.png](/api/images/2df6fcc7-2c1d-46be-9bda-ab60b82404e8/df9fe51a-4b98-4f16-a728-7461b7a76f78/jolli-support-docs-1776993369310/219fb895-6a71-46bd-a356-f8b2fb79ce9a.png) Each layer does one job: - **Jolli Memory** captures the "why" behind every AI-assisted commit - **Jolli Spaces** is where your team creates, reviews, and maintains docs that stay in sync with code - **Jolli Sites** publishes everything to beautiful, branded documentation sites ## Your first sign-in Signing in for the first time lands you on **Set up Jolli for your team**. It carries the install command for your platform, the other places Jolli can be installed, and a short explanation of where the data comes from and when it arrives - because a new workspace is empty until someone installs Jolli Memory and signs in. Everyone sees this page on their first visit, not only whoever created the workspace. You can leave it whenever you like; the sections below are the longer version of the same three paths. ## For developers: Never lose context again Tired of your AI coding sessions disappearing into the void? **Jolli Memory** automatically attaches structured summaries to every git commit and your Jolli Memory Bank, so the reasoning behind changes lives on - not just the code. It's available as a CLI, plus editor extensions for VS Code, Cursor, Windsurf, and IntelliJ. Everything runs locally on your machine. → [Get started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) Working in Claude Code, Cursor, or Codex? Jolli also ships as a plugin that sets itself up - see [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). ## For teams: Write your docs once, keep them current **Jolli Spaces** lets you import existing Markdown, use AI to keep docs synced with your codebase, and publish when ready. No more rewriting the same documentation across three different tools. → [Set up Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) ## For publishing: Ship beautiful docs to your domain **Jolli Sites** builds and deploys documentation sites at your own domain (like `docs.yourdomain.com`). Choose from preset themes or customize, set granular access controls, and let Jolli handle the rest. → [Learn about Jolli Sites](https://docs.jolli.ai/jolli-sites) ## Related - [What's New in Jolli](https://docs.jolli.ai/whats-new-in-jolli) - everything that has shipped, newest first. - [Settings](https://docs.jolli.ai/settings) - your profile, the people in your organization, and the roles that govern what they can do. --- # What's New in Jolli Source: https://docs.jolli.ai/whats-new-in-jolli Everything that has shipped, newest first. Each entry is one release day, grouped by the part of Jolli it affects. Versions are not listed in the headings: an entry usually spans the CLI, the editor extensions and the web app, which version independently. ## September 1, 2026 Highlights: the Spaces and Workflows command plugins now need a current CLI. ### Jolli Memory - **The Spaces and Workflows plugins need the CLI at 0.99.17 or later.** Both now take the list of Jolli web addresses from the CLI itself instead of keeping their own copy, so a CLI that learns a new address teaches them the same one with no plugin release. On an older CLI the plugin is skipped rather than loaded, which means `jolli space` and `jolli workflow` stop appearing at all rather than reporting an error. If either goes missing, run `npm i -g @jolli.ai/cli`. How addresses are judged is unchanged. See [Reference](https://docs.jolli.ai/jolli-memory/reference). ## August 31, 2026 Highlights: CLI 0.99.17 on every channel, with the JetBrains plugin level again. ### Jolli Memory - **The JetBrains plugin is up to date with the others.** It had been a release behind; it now ships 0.99.17 alongside npm, the VS Code Marketplace and Open VSX, so a JetBrains setup receives everything announced for August 24 and August 28. - **The Claude Code, Cursor and Codex plugins are one release behind from today.** Each bundles its own copy of Jolli, currently 0.99.16, so this release reaches them at their next plugin update rather than immediately. - Bug fixes and performance improvements. ## August 29, 2026 Highlights: the agent plugins pick up the August 28 release. ### Jolli Memory - **The Claude Code, Cursor and Codex plugins now bundle CLI 0.99.16**, so everything in the August 28 entry reaches them too, Hermes Agent capture included. Take the plugin update and there is nothing else to do. - Signing out of Codex or Cursor now names Hermes among the logins that keep local memory generation working. ## August 28, 2026 Highlights: Standup, Coaching, Skills and MCPs join the Dashboard in your browser, Hermes Agent becomes the eleventh captured agent, and the Team views narrow to owners and administrators. ### Jolli Memory - **Hermes Agent conversations become memories.** Sessions are found in Hermes' own database, and on macOS and Linux a session-end hook records each one as it finishes. That makes fourteen sources across eleven agents. Every Hermes profile is set up, not only the default one. Turn it off with `jolli configure --set hermesEnabled=false`. The JetBrains plugin does not read Hermes sessions yet. See [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture). - **Hermes can also generate your memories.** It joins Claude Code, Codex, Cursor, OpenCode and Kimi Code as a `local-agent` option, so summaries can run through the agent you already have with no API key: `jolli configure --set aiProvider=local-agent --set localAgentTool=hermes`. See [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory). - **See where each repository syncs to.** Settings now shows which Jolli Space a repository is connected to, in both the VS Code extension and the JetBrains plugin. - **A snappier dashboard on large repositories**, with slow spots easier to spot so `jolli doctor` can point them out. - **The Decisions card is accurate again.** ### Jolli Memory Dashboards - **The Dashboard in your browser is now five pages, under My Dashboard and Team Dashboard.** Alongside **Dashboard** there are **Standup**, **Coaching**, **Skills** and **MCPs**, each taking the same date range and repository picker. See [The Web Dashboard](https://docs.jolli.ai/jolli-memory/the-web-dashboard). - **Standup** lays out a week of committed work as day columns, with a pager to move between weeks. Only work that reached a commit and synced appears. - **Coaching** reads your journeys against your own earlier line: how many in the window, plan-first share, cost and recall, with individual journeys openable as a trace. On the Team view it reports across members. Marked **Beta**. - **Skills** and **MCPs** each get a full page, breaking every skill or MCP server out day by day with its runs and tokens, at more grain than the cards on the overview. - **The Team views need View Team Memory Activity, and Member no longer carries it.** Owners and administrators have it. To give it to someone else, move them to a custom role that includes it. This narrows what the August 21 entry described. See [Settings](https://docs.jolli.ai/settings). ### Onboarding & Settings - **The hosted assistant endpoint address is on the Settings page**, with a button to copy it. It is the only address the endpoint accepts: a connection arriving on a workspace subdomain or a custom domain is turned away with a message naming the right one. - **Authorizing an AI assistant now says what it can do, not just what it can read.** The consent screen and **Settings → Connected apps** both describe the tool permission as reading content and starting or cancelling Workflow runs that can add or change content. ## August 24, 2026 Highlights: Cursor work is captured as it finishes, the local dashboard gains an MCPs page, and all three agent plugins ship the same evening. ### Jolli Memory - **Cursor work is captured right away.** Cursor conversations are recorded as they finish, so they appear without waiting for a commit or for the dashboard to be opened. In the Cursor plugin this arrives as a session-end hook the plugin installs itself. - **An MCPs page in the local dashboard**, showing which MCP servers your agents called day by day, with the calls and tools for each. It ships in the plugins' bundled dashboard too. See [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). - **A much faster local dashboard**, especially on large repositories. - **Turning an agent off now applies everywhere.** Switch a source off in Settings and it stops appearing across the dashboard, not just in the sidebar. - The `dashboard` action takes a port, or a request for the address without opening a browser. Naming a page is no longer needed: the dashboard's own navigation reaches every page once it is open. - **The Claude Code, Cursor and Codex plugins carry all of this**, published the same evening and bundling the same 0.99.15 engine as the CLI. ## August 21, 2026 Highlights: a Dashboard in your browser that reports what your agents did for you and for your team, memories that record which AI tool did the work, and a repair command for memories stranded by a rebase. ### Jolli Memory - **A Dashboard when you open Jolli in your browser**: the Analytics page is now **Dashboard**, with **My** and **Team** views. It reports your memories, decisions, skills, MCP calls, tokens and estimated spend over a range you pick, filtered to the repositories you choose. Old `/analytics` links land on the new page. See [The Web Dashboard](https://docs.jolli.ai/jolli-memory/the-web-dashboard). - **The Team view needs a permission**: **View Team Memory Activity**. Every built-in role has it, so the page is open by default. To close it, move people to a custom role without it. - **Your machine now sends session statistics to your organization**, which is what fills that Dashboard: tokens, estimated cost, model names, tool and skill names, and session titles, for every repository Jolli is enabled in. It is on once you are signed in. Conversation text and code are never part of it. Turn it off with `jolli configure --set syncSessions=false`, or in the local dashboard under **Settings → Sync to Jolli**. What it does and does not send is spelled out in [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). - **See which agent did the work**: memories record which AI tool each conversation, commit and skill came from, and both dashboards break your work down by agent. References and memories carry their source's own badge. - **Two new pages in the local dashboard**: **Skills** shows which agent used which skill, and **Coaching** reads your journeys for plan-first share, top skill, cost and recall, calling out your smoothest and hardest. **Daily Standup** is now a week at a time, and **Knowledge** and **Graph** are switched on under **Settings → Advanced**. See [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). - **`jolli repair-memory` reattaches a lost memory**: when an amend, rebase or squash rewrites a commit, its memory can end up stuck on the old hash while the new commit shows nothing. `jolli doctor` now flags it and `jolli repair-memory` puts it back, with `--status` to preview first. Safe to run twice, and it backs up anything it replaces. - **Pick a model per local agent**: `localAgentModel` now applies per tool, so Claude Code and Codex each keep their own default and choices. In the editors, **Settings → AI Summary**. - **Cleaner conversation history**: empty conversations no longer clutter your archives, conversations that grow after import are picked back up, and Codex transcripts parse more reliably. - **SSH host aliases are recognised**: a repository cloned through a `~/.ssh/config` alias binds to the same identity as one cloned by its real host. - **The Claude Code, Cursor and Codex plugins are level with the CLI**: each now bundles version 0.99.14, so everything above reaches the plugins too, including the session statistics that fill the Dashboard. Take the plugin update and there is nothing else to do. - **Open the local dashboard from the conversation**: a new `dashboard` action in all three plugins - `/jolli:dashboard` in Claude Code, `/jolli-dashboard` in Cursor, `$jolli:dashboard` in Codex. See [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). - **Cursor: every skill now ships with the plugin.** All twelve are available from the moment you install, including recall and search, which used to appear only after you had opted a repository in. - **Cursor: if you already had the plugin, remove the marketplace and add it again.** It was renamed, and Cursor identifies a marketplace by its name, so the old entry keeps reporting that you are up to date and will never offer the update. In **Customize**, remove **Jolli Cursor Marketplace**, add `jolliai/jolli-cursor-plugin` again - it now appears as **Jolli Cursor** - then reinstall and restart Cursor. Your memories and settings are untouched, and this is a one-time step. See [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). ### Jolli Spaces - **Article search reads content, not just titles**: searching from an AI agent now matches article bodies as well as titles, and every result comes back with a link you can open, a plain-text snippet of the match, and a relevance score. A search across several Spaces is ranked before it is capped, so the best matches survive. - **Approving an agent only offers workspaces where it will work**: the approval screen lists the workspaces that have this kind of connection turned on, and says so plainly when none of yours do, instead of connecting and then refusing every request. ## August 17, 2026 Highlights: the Jolli plugin is now available for Cursor and Codex, alongside Claude Code. ### Jolli Memory - **Jolli Memory for Cursor**: add `jolliai/jolli-cursor-plugin` as a marketplace in Cursor, then install **Jolli Memory** from **Customize** and pick a project or user scope. You get the Memory skills, the MCP tools, and a bundled runtime, so there is no CLI to install. Repositories are opted in one at a time with `/jolli` or `/jolli-init` rather than automatically, so a repository you only browsed is left alone. - **Jolli Memory for Codex**: run `codex plugin marketplace add jolliai/jolli-chatgpt-plugin`, then `codex plugin add jolli@jolli-marketplace`. Review and trust the Jolli hook in `/hooks` before it can do anything, then start a new session; the MCP tools arrive from the session after that. - **A branch briefing on all three**: Cursor and Codex now get the automatic session-start briefing that was previously Claude Code only, so your prior reasoning on a branch is in context from the first message. - The Claude Code page is now [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent), covering all three plugins and how they differ. ## August 15, 2026 Highlights: hosted agents can sign in to Jolli themselves, instead of being given an API key. ### Jolli Spaces - **Connect an agent by signing in**: an agent that supports connectors can now send you to Jolli in the browser to approve the connection, so there is no key to create or paste. Add `https://jolli.ai/mcp` and approve. - **You pick which organization the agent reaches**: the approval screen asks, and checks the answer against the organizations you belong to. If you were invited to one and had not opened it yet, approving finishes setting up your account there. - API keys still work for anything that cannot open a browser. See [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). ## August 14, 2026 Highlights: the dashboard runs in your terminal and gains Knowledge and Graph views, the wiki rebuilds when you ask, three more reference sources, and your agent can write a memory to Jolli Cloud. ### Jolli Memory - **The dashboard runs in your terminal**: `jolli dashboard` serves until you press Ctrl+C instead of leaving a server behind, so `jolli dashboard --stop` is gone. Run it again and it replaces the one already running. See [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). - **Knowledge and Graph join the dashboard**: browse your wiki and view the knowledge graph in the page, next to My Dashboard, Daily Standup, and Memories. The Repositories page is gone, replaced by a picker that scopes what you are looking at. - **The wiki and graph rebuild when you ask**: they no longer rebuild after every commit, so commits stay fast and nothing spends AI credits unprompted. For the old behavior: `jolli configure --set wikiRebuild=auto`. - **Three more places your references come from**: Vercel deployments, Figma design files, and Sentry issues now appear on your memories, bringing the total to fifteen sources. - **Your dashboard finds more conversations**: it now reads your agents' session history from the last seven days, not just what was already recorded, and says in one line what it picked up. - **Pushes stop promising memories that were never yours**: after a rebase the pre-push check counted commits already on the remote. It now counts only what your push adds. - **MCP tools answer for the right repository**: started outside a project, the tools that need one are hidden rather than returning an empty result that reads as "no memories here". - **`jolli doctor` gains `--schema-log` and `--mark-migration`**: inspect your memory database's schema history, or repair it when a migration record went missing. ### Jolli Memory in VS Code - **Open your dashboard from the sidebar**: a new toolbar button, also **Jolli Memory: Open Dashboard** in the Command Palette, runs it in a terminal so you can watch it work and stop it with Ctrl+C. - **A wiki banner**: the sidebar shows how far behind your wiki and graph are and rebuilds them on one click. Dismiss it and it returns once there is something new. ### Jolli Memory in JetBrains IDEs - **The FILES panel matches VS Code**: discard and "leave out of this memory" moved onto each row as hover buttons, and committing lives on the Current Memory card. - **Discarding a file is reliable**: renamed, copied, untracked, and conflicted files all behave now, the confirmation matches what happens, and a failure tells you instead of reporting success. ### Jolli Spaces - **Your agent can write a memory to Jolli Cloud**: the hosted MCP surface gains `create_remote_memory`, so an agent can capture a decision or a note without leaving the conversation. It writes to your organization's default memory Space, or one you name. - **One address for the hosted MCP endpoint**: connect at `https://jolli.ai/mcp`. A connection on a workspace subdomain or a custom domain is now turned away with a message naming the address that works, instead of failing later for no clear reason. ### Jolli Memory in Claude Code The plugin moves to 1.0.3 and its engine is level with the CLI again, so everything above is available through the plugin. Its commands and skills are unchanged. Quit Claude Code completely and reopen it so the update takes effect. ## August 10, 2026 Highlights: a local dashboard for your memories, a one-way move to local database storage, Kimi Code sessions become memories, a new minimum Node version, and the Claude Code plugin catching up to the CLI. ### Jolli Memory - **Node 22.13 or newer is now required**: previously 22.5. The package refuses to install on an older runtime, so upgrade Node before running `npm install -g @jolli.ai/cli`. If an install looks like it worked but leaves you with no `jolli` command, this is almost always why. The VS Code extension now needs VS Code 1.101 or newer; on 1.100 and earlier the Marketplace stops offering updates, so your installed version quietly stays where it is. - **A dashboard in your browser**: `jolli dashboard` starts a private server on your machine and opens a view of your memories, per-repo stats, and a standup summary. Nothing is uploaded. Stop it with `jolli dashboard --stop`. See [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). - **Move a repository's memories to a local database**: `jolli cutover` makes SQLite the source of truth for a repository. This is one way. It freezes the repository's git branch, and `jolli enable` will not unfreeze it. Run `jolli cutover --status` first to see where a repository stands, and `jolli cutover --probe` afterwards to check the frozen branch for drift. - **Kimi Code conversations become memories**: sessions from Kimi Code CLI are discovered automatically, with references and skill usage, and no hook to install. Jolli also registers its MCP server for Kimi Code, bringing the total to eleven hosts. - **Skills travel with the memory**: pushing a memory or a branch to a Space now sends the skills the work used as separate articles, next to plans, notes, and references. - **Squash memories keep your working context**: plans, notes, and references you activated during a session are archived into squash and merge memories instead of being left behind. ### Jolli Memory in JetBrains IDEs Same release as the CLI and VS Code this time, so everything above applies here too. The plugin now needs Node 22.13, up from 18. - **The tool window is redesigned**: one **+** button for plans, notes, and snippets, hover actions on every row, and a new status overlay carrying Sign In, **Sync Now**, and a **Disable** that turns Memory off for a whole repository. - **Kimi Code, Devin, Cline, and Antigravity reach the sidebar**, each with a Status row and a switch under **Settings → AI Agents**. - **Skills used**: a new row in CONTEXT and on every memory, listing each skill with its count and first and last use. ### Jolli Memory in Claude Code The plugin moves to 1.0.2. Its commands and skills are unchanged, but the engine inside it was two releases behind and now matches the CLI, so everything above is available through the plugin. - **Nothing to install by hand**: Claude Code fetches the plugin itself, and the new engine arrives with it. Quit Claude Code completely and reopen it so the update takes effect. ## August 7, 2026 Highlights: connect a hosted AI agent straight to Jolli with an API key, published Sites gain robots.txt and sitemap.xml, and a new Set up page greets everyone on their first sign-in. ### Jolli Memory - **Point a hosted agent at Jolli**: agents that cannot run a local process can now connect over the web at `/mcp` using a Jolli API key as a bearer token. The endpoint works on your workspace URL, a tenant subdomain, or a verified custom domain. Your key decides which workspace it reaches, so there is nothing else to configure. - **A hosted agent can read your team's memory**: new tools let a connected agent search your organization's memory and open a specific memory document, scoped to what the key's creator can view. Documentation search is unchanged and still leaves memory and personal Spaces out. ### Jolli Sites - **Published sites now emit `robots.txt` and `sitemap.xml`**: every site gets `robots.txt`, and a sitemap once the site has a canonical web address. Sites behind a sign-in serve `Disallow: /` and no sitemap. - **`/llms.txt` is sharper**: page links and source lines are now absolute, cross-references between articles resolve to real URLs, sections follow your navigation instead of alphabetical slugs, and each page contributes a single heading. - **Give your site a summary**: a new **Site Description** in Site Settings renders as the opening line of `/llms.txt`, so an agent landing cold knows what the site is. An edited summary or a newly attached domain now shows up as a pending change, so you know a republish is due. ### Onboarding & Settings - **A Set up page is the new first stop**: signing in for the first time now lands on **Set up Jolli for your team**, with the install command for your platform, the other install targets, and a short explanation of where the data comes from and when it arrives. Whoever can invite people also gets an **Invite your team** card. ## August 2, 2026 Highlights: the JetBrains plugin catches up, and the `jolli-pr` skill is retired. ### Jolli Memory in JetBrains IDEs The IntelliJ plugin moves to 0.99.10, past 0.99.9, so a JetBrains IDE now has what the CLI and VS Code picked up on July 31 below, including reference ids and the per-repository push toggle. The local agent picker from that entry arrives here too, under **Settings → AI Summary → Local Agent**. Update the plugin from **Settings > Plugins** and restart the IDE when prompted. New to JetBrains in this update: the first-run screen offers **Use a local agent CLI** alongside the Anthropic-key and Jolli sign-in options, so you can get started without any key. Also in this update: - **The `jolli-pr` skill has been removed**: only `jolli-recall` and `jolli-search` are installed now, and upgrading removes the old skill file for you. Turning a branch's memories into a pull-request description is still available through the `get_pr_description` MCP tool and the `jolli pr-description` command. - **Sessions started in a subdirectory are found**: an AI session begun in a nested folder is attributed to the repository that contains it instead of being missed. - Memory generation from GUI git clients such as SourceTree and IntelliJ's own commit UI is fixed, unsaved editor buffers are staged before an AI commit, and the full branch commits list is restored. ## July 31, 2026 Highlights: Memory registers itself with three more AI agents, you can turn one repository's pushes off without turning capture off, a running Workflow can be cancelled from the button that started it, and a Space can restrict which repositories push into it. ### Jolli Memory - **Three more agents are wired up for MCP**: Cline, Devin, and Antigravity now get the `jollimemory` server registered for them, bringing the total to ten. For Cline this is the VS Code extension, once per flavor you have installed; the Cline CLI keeps no MCP config of its own. - **Agents are detected more reliably when you enable**: several hosts could previously be skipped, either because detection needed a newer Node version than the editor extension runs on, or because the agent had not been used yet and so looked absent. Detection no longer depends on either. Registration still happens when you run `jolli enable`, so install the agent first. - **Choose the local agent that writes your memories**: Codex, Cursor, OpenCode, and Kimi Code join Claude Code. If exactly one is installed and working it is picked automatically and named back to you; otherwise you choose from the ones found on your machine. - **Turn pushing off for a single repository**: `jolli push-control --disable` stops that repo from sending memories to a Space while still recording them locally, and `--enable` turns it back on and sends what was held. VS Code has the same control per repository on its Settings page. - **See whether the Memory Bank is writing**: `jolli status` and the VS Code Settings page now always show the Memory Bank's state, naming the folder in use or saying why nothing is being written. - **Skill usage is captured**: a commit now records which skills the session entered and roughly what they cost, as a table in your Memory Bank folder and live in the VS Code sidebar. Claude Code, Codex, and OpenCode report it. - **Every memory has a short reference id**: memories now carry a `JM-` id you can quote to a teammate, shown in both editors and in the web app. Selecting it in an editor copies it. - **A repository you turned off stays off**: the VS Code sidebar and AI commit messages now respect that, and a turned-off project is left alone. ### Workflows - **Cancel a run from the button that started it**: a Workflow card's primary button reads **Run now** while the Workflow is idle and changes to **Running...** while a run is in flight. Choosing it then asks you to confirm, and cancelling stops the run without publishing anything. Cancelling is no longer buried in the overflow menu. Pausing a Workflow still leaves a run that is already going to finish, or to be cancelled. ### Jolli Spaces - **Restrict which repositories push into a Space**: Jolli Memory Spaces have a new **Restrict pushes to listed repos** setting, off by default. Turn it on and only the repositories already registered may push; anything else is refused and can no longer add itself. Repos already listed keep working, and turning it on never removes one. - **The auto-apply setting is hidden where it does not apply**: Spaces whose repository Jolli manages already merge automatically, so the toggle no longer appears for them. ## July 25, 2026 Highlights: the install script is now the quickest way to get set up. ### Jolli Memory - **The install script is now the recommended way to install**: one command installs the CLI, installs Node.js if you need it, and runs the guided setup. See [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory). ## July 24, 2026 Highlights: four new AI agents captured, `/llms.txt` on every published Site, and workflow run-completion notifications by Inbox and email. ### Jolli Memory - **More agents captured**: Memory now captures **twelve sources across nine agents**, adding **Cursor CLI** (`cursor-agent`), **Cline** (the VS Code extension and the CLI), **Devin**, and **Antigravity**. All are discovered automatically, no setup. - **Ships as a Claude Code plugin**: install Jolli from Claude Code's plugin marketplace with `/plugin marketplace add jolliai/jolli-claude-plugin`, then `/plugin install jolli@jolli-marketplace`. Restart Claude Code, open a session in a git repository, and Memory sets itself up: the git hooks, Memory's MCP tools, the `/jolli:status`, `/jolli:init`, `/jolli:login`, `/jolli:logout`, and `/jolli:timeline` commands, the `/jolli:recall`, `/jolli:search`, and `/jolli:push` skills, and a `/jolli` menu that lists them. No CLI install, no API key, and no sign-in needed to start generating memories. The plugin covers Jolli Memory; `jolli space`, `jolli site`, and `jolli workflow` still come from their own CLI plugins. See [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). - **Simpler setup**: if a local Claude Code CLI is detected, `jolli enable` uses it automatically (its subscription, no key, no menu). - **Smarter references**: **Context7** library lookups are now tracked as lightweight bookmarks, and **Codex now captures Slack threads** referenced in a conversation (previously Claude Code only). - **Memory in the web app**: an interactive **knowledge-graph viewer** for your Memory spaces, and a **Copy Recall Prompt** button on Memory summaries. ### Workflows - **Notify on completion**: post a run summary to your **Inbox** when a run finishes, to the Space owner, the Workflow owner, and/or all Space members. - **Run summaries by email**: each recipient also gets an email with the same summary and links shown in their Inbox, plus a **View in inbox** button that opens that exact notification. Email goes to the recipients you already picked, with no separate setting to switch on. - **Email sent on completion**: the **Workflow complete** notification shows a preview of the email that went out, including who it was delivered to and its subject line. - **Inspect runs from the command line**: for a git-backed Space cloned on your machine, the new `jolli workflow` plugin reports which Workflows can run locally, a Workflow's run history, and the status of a run as it finishes. Output is JSON, so it drops into scripts and agent recipes. Install it with `npm i -g @jolli.ai/cli @jolli.ai/workflow-cli`. - **Duplicate or move a workflow**: copy a workflow, or move it to another Space, right from the workflow card. - **Run now** is now a one-click primary button on every workflow card. - **Richer run history**: each run shows how many documents it created, edited, and deleted, and whether the result was applied automatically or opened as a pull request. ### Jolli Sites - **Built for AI**: every published Site now generates **`/llms.txt`** and **`/llms-full.txt`** at its root and advertises them in each page's ``, so AI clients like Claude, Cursor, and ChatGPT can ingest your docs in one shot. ### Onboarding & Settings - **A friendlier first run**: name-free signup, plus a ready-to-use **Shared Space** (seeded with a Welcome doc) created for you automatically. - **Rename your workspace** anytime from the new **Settings → Workspace** page. - **Invite your team** from a single dialog: one person or a CSV. ## July 17, 2026 Highlights: generate memories with your own local AI, a guided first run of the `jolli` command, three more reference sources, and workflow run history you can click through. ### Jolli Memory - **Write memories with your own AI**: a new **local-agent** provider drives a locally-installed Claude Code to generate your memories using its own login, with no API key and no Jolli proxy call. Turn it on in the extension settings or with `jolli configure --set aiProvider=local-agent`. - **A guided front door**: running `jolli` with no arguments now walks you through signing in, fixing a missing AI provider key, and turning recent commits into memories, all from one prompt. - **Run a workflow from your agent**: the new `/jolli-local-run` skill runs a Jolli workflow on your own machine, with no Jolli AI credits, and lands the result in a git-backed Space through a branch and pull request. Remote runs work too. - **More reference sources**: conversations that mention **monday.com**, **Asana**, or **Confluence** now capture those items as references. - **Your knowledge graph follows you**: graphs now sync across the machines you sign in to, and can be embedded on the web. - **One menu for everything**: type **`/jolli`** in Claude Code for a single menu that lists the Jolli skills (recall, search, PR, run a workflow) and the Jolli tools available in your session, then runs the one you pick. - **More ways to install**: new PowerShell and Windows Command Prompt install scripts, plus one-click install buttons for VS Code, Cursor, and JetBrains. - **Clean uninstall**: `jolli uninstall` finds and removes every Jolli install and config on your machine, and never touches your memories. ### Workflows - **Run history you can click through**: open **History** on any workflow to see past runs, jump straight to the article a run wrote or the pull request it opened, and link directly to a specific run. - **Run now with custom values**: when a workflow's prompt uses variables, **Run now** opens a form to set values for that run only, without changing the workflow's saved defaults. ### Jolli Spaces - **Wiki-style links**: relative links between articles now open the linked article in place, and heading links jump to the right spot on the page. - **Cleaner article links**: article web addresses are now readable and built from the article title instead of an internal id, so a shared link makes sense at a glance. ## July 10, 2026 Highlights: memory that syncs on every push, Slack and Zoom captured as sources, the IntelliJ extension catching up to VS Code, and the Jolli Agent on the newest Claude models. ### Jolli Memory - **Sync on every push**: once you are signed in, `git push` automatically syncs the pushed commits' memory to your Jolli Space in the background, and retries anything that did not make it on the next push. Turn it off with `syncOnPush: false`. - **More reference sources**: **Slack** threads and **Zoom** meetings mentioned in a conversation are now captured as references. - **The IntelliJ extension catches up to VS Code**: the JetBrains plugin gains token usage and estimated cost on each memory, Markdown export, read-only share links, and a card that builds memories from your existing commit history. - **More agents captured**: **GitHub Copilot** and **Copilot Chat** conversations are now captured, and **Codex** sessions resume correctly and stay scoped to the current repo. - **Usage and cost on shared memories**: pushed memory articles now show a **Task usage** line with total tokens and an estimated cost, now priced by the model that generated each memory rather than a flat rate. - **Global AI instructions are now opt-in**: Jolli asks before adding its skill-preference block to your global instruction files, and will not add it without your go-ahead. ### Jolli Spaces - **Guided Space setup**: creating a Space now lets the Jolli Agent generate documentation from your connected sources or import your existing docs as-is, with a live progress view that keeps running if you step away. - **The newest Claude models**: the Jolli Agent now runs on Claude Opus 4.8 and Sonnet 5 with extended thinking, for stronger document generation and analysis. - **Fewer naming collisions**: creating a folder or document with a name that already exists now adds a number instead of failing. ### Onboarding & Settings - **Clearer access errors**: opening a shared link that belongs to an account you are not a member of now names that account and offers to sign in with a different one. ## Related - [Welcome to Jolli](https://docs.jolli.ai/welcome-to-jolli) - the three layers and where to start. - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install the CLI and generate your first Memory. --- # Getting Started with Jolli Memory Source: https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory When you work with an AI coding agent, the reasoning behind every decision lives in the conversation: why you picked this approach, what alternatives you rejected, what dead ends you hit. The commit message captures none of it. A week later, you can't remember why; neither can the teammate who asks. Jolli Memory captures that context automatically. On every commit, a background worker reads your AI session transcript and your git diff, then attaches a structured summary to the commit: **Why**, **Decisions**, **Implementation**. The commit returns instantly; the summary appears shortly after. ## What you get - Structured commit summaries - **Why**, **Decisions**, **Implementation** - attached to each commit and stored with your repo, not in any cloud. Your git history stays normal. - **Recall** - feeds a branch's past reasoning into your next AI session so you don't start from zero. - **Search** - find a past decision across every branch. - **Share in Jolli** - optional, publish a Memory to your team. - Runs headless from the **CLI** in any terminal, editor, or CI. An optional editor extension (VS Code, Cursor, Windsurf, IntelliJ) adds a visual sidebar and in-editor actions - see **Editor extensions**, below. Keep coding with your AI the way you already do. Memory works in the background: you do not change your workflow, and reviewing or curating what gets captured is optional. Memory captures from eleven AI coding agents across fourteen sources: **Claude Code**, **Codex CLI**, **Gemini CLI**, **OpenCode**, **Cursor** (the Composer IDE and the `cursor-agent` CLI), **GitHub Copilot** (both the Copilot CLI and VS Code Copilot Chat), **Cline** (the VS Code extension and the CLI), **Devin**, **Antigravity**, **Kimi Code CLI**, and **Hermes Agent**. Use more than one in the same repo and each Memory names the agent that produced it. For exactly how each is captured, see [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture). ### Privacy Private and local-first. Your summaries and transcripts are stored with your repo, not in any cloud. Generating a summary does send your transcript and diff to the LLM (Anthropic directly, or the Jolli proxy, which holds them only for that request and never stores them); no Memory content is published to anyone else until you explicitly Share a Memory. Licensed under Apache 2.0. Two things do leave your machine on their own, both on by default, and they are not the same thing: - **Content-free usage telemetry.** It never sends your code, file paths, commit messages, diffs, transcripts, Memory content, or repo or branch names, and the payload carries no account identifier (though when you are signed in, events upload under your Jolli key, so they can be attributed to your account on our end). Turn it off with `jolli telemetry off`, or by setting `DO_NOT_TRACK` to any non-empty value other than `0`. - **Session statistics, once you are signed in.** These are not content-free. They carry token counts, estimated cost, model names, tool and skill names, and each session's title, for every repository Jolli is enabled in rather than only the ones you shared. Conversation text and code are never part of them. Turn them off with `jolli configure --set syncSessions=false`. For exactly what each one sends and every opt-out path, see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). ## Install the CLI This page follows the CLI, which works in any terminal, any editor, and in CI. Jolli Memory also ships as a plugin for Claude Code, Cursor and Codex, and as an extension for VS Code and JetBrains. For every option and how to choose, see [Install Jolli Memory](https://docs.jolli.ai/jolli-memory/install-jolli-memory). **macOS, Linux and WSL** ```bash curl -fsSL https://jolli.ai/install.sh | sh ``` **Windows PowerShell** ```powershell irm https://jolli.ai/install.ps1 | iex ``` The script installs the CLI, installs Node if you need it, then hands off to the guided setup, so you finish with Memory already enabled in your repo. That guided setup is the bare `jolli` command: it does the work of `jolli auth login`, `jolli enable`, and `jolli status` in one pass, and on a repo that already has commits it offers to capture your recent history right then. Run `jolli` on its own any time to re-enter it, or `jolli --help` to see every command. Jolli Memory needs **Node 22.13 or later**. If the script finishes and there is still no `jolli` command, that is almost always the Node version, and it fails quietly. See [Install Jolli Memory](https://docs.jolli.ai/jolli-memory/install-jolli-memory) for why, or [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) to fix it. The guided run ends by opening [the local dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard) and serving it until you press **Ctrl+C**, so Ctrl+C there loses nothing. Prefer to run each step by hand, or script it for CI? The manual path is **Sign in** then **Enable in your repo**, below. ## Sign in Jolli Memory needs a way to generate summaries. Three options: **Installed one of the agent plugins?** This is already handled. Each plugin records its own agent as the tool that writes your summaries, so Claude Code, Cursor and Codex all generate Memories with no credential. Skip ahead to **Make your first commit**, and sign in only when you want to share memories to a Space. - **Sign in with Jolli (recommended)** - OAuth into Jolli and use Jolli's LLM proxy. Choose this if you might Share to your team later. ```bash jolli auth login ``` - **BYOK (bring your own key)** - Memory calls Anthropic directly with your key. Choose this if you already pay Anthropic, or want to evaluate before creating a Jolli account. ```bash jolli configure --set apiKey=sk-ant-api03-... ``` - **Use a local agent CLI (no key)** - if you already have one of these installed and signed in, Memory can drive it to generate summaries through its own subscription, with no Anthropic key and no Jolli account. ```bash jolli configure --set aiProvider=local-agent --set localAgentTool=claude-code ``` Six agents are supported. Use the id in the left column as the `localAgentTool` value: | Id | Agent | How to sign in | |---|---|---| | `claude-code` | Claude Code | Run `claude` once and sign in to your subscription. | | `codex` | Codex | Run `codex login` to sign in with your ChatGPT plan. | | `cursor-agent` | Cursor | Run `cursor-agent login` to sign in to Cursor. | | `opencode` | OpenCode | Run `opencode auth login` to connect a provider. | | `kimi` | Kimi Code | Run `kimi login` to sign in to your Moonshot account. | | `hermes` | Hermes | Run `hermes setup` (or `hermes model`) to configure a provider. | Note that Cursor's id is `cursor-agent`, not `cursor`. If the agent's binary is not on your `PATH`, add `jolli configure --set localAgentPath=/path/to/binary`. This powers summary generation only; Sharing to a team Space still needs a Jolli API key. You can switch or add another later. For CI or scripts you want a personal Jolli API key instead - see [Jolli Memory in CI and Automation](https://docs.jolli.ai/jolli-memory/jolli-memory-in-ci-and-automation). ## Enable in your repo `jolli enable` is the single command that sets Jolli Memory up in a repository - it installs everything and then helps you configure a credential. **Install your AI agents first.** `enable` wires up whichever agents it finds on your machine at the moment you run it, and it does not repeat that on its own. An agent you install later stays unregistered until you run `jolli enable` again. Run it from the root of a git repo: ```bash jolli enable jolli status ``` `enable` does three things in one pass: 1. **Installs the git hooks** that drive Memory - `post-commit`, `post-rewrite`, `prepare-commit-msg`, `post-merge`, and `pre-push`. 2. **Wires up your coding agents** - agent hooks for **Claude Code**, **Gemini CLI**, and **Hermes Agent** on macOS and Linux, plus the MCP server and Memory's skills, registered into every agent it detects. The other eleven sources are discovered automatically and need no hook. 3. **Sets up a credential** - in an interactive terminal (skip with `-y`), `enable` helps you choose how summaries get generated. If exactly one local agent CLI is already installed and working, it is selected automatically, with no key and no menu. Otherwise you get the four choices above. So you do not have to run `jolli auth login` first - `enable` can do the sign-in for you. `status` then confirms your hooks, credential, and detected agents. A fresh repo shows `Stored memories: 0` until your first commit generates one - that's expected, not a misconfiguration. Handy flags: `-y` skips the interactive prompts (for CI or scripts); `--integrations-only` sets up the MCP server and skills without installing any git or agent hooks (for hosts that manage their own, such as the IntelliJ plugin); `--cwd ` targets a specific repo. **Now restart your AI agent.** This is the most common reason a first Memory doesn't appear. Which agents need it, and why every agent needs one restart before Memory's MCP tools show up, is covered in [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture). ## Make your first commit Open your AI agent and code normally. Ask it to make a small, real change. Conversational pairing is the point - the more reasoning lives in the transcript, the better the Memory. Commit without an AI session and you still get a Memory, just a thinner, diff-only one. Stage and commit as usual: ```bash git add git commit -m "Fix tile generation when grid snaps are fractional" ``` The commit returns immediately. In the background, Memory reads your transcript and the diff, generates a summary, and stores it with the commit - usually within about 10 to 20 seconds. **Already have history?** Running `jolli` offers a backfill automatically on a repo that already has commits, and the editor extension prompts for the same on enable. To run it yourself, `jolli backfill` creates Memories for commits made before you enabled Jolli (Claude Code transcripts only; commits with no attributable transcript get a diff-only summary). It defaults to the last 20 commits - use `--last ` for more, or `--all` for every commit missing a Memory. ## See your first Memory From the CLI: ```bash jolli view # list recent Memories jolli view --commit 1 # open the latest commit's Memory ``` If `jolli view` shows nothing right after committing, the summary is still generating - wait a few seconds and run it again. `--commit` takes a numeric index (`1` is the latest) or a commit-hash prefix; `HEAD`, branch names, and tags are not recognized. Each Memory leads with a Quick recap, then a card per topic with labeled callouts: - **Why this change** - what problem the commit solved and why now. - **Decisions behind the code** - trade-offs, alternatives rejected, non-obvious choices. The part that disappears without Memory. - **What was implemented** - what was built and how. In the editor extension, the same Memory opens in a visual Memory view with editable callouts (see **Editor extensions**). ## Recall Recall feeds a branch's past reasoning back into your next AI session. In Claude Code, and in Cursor or Codex with the Jolli plugin installed, it is **automatic**: a compact `[Jolli Memory — ]` briefing prepends the conversation at session start. Every other agent pulls it on demand with `jolli recall`, or with the recall skill for that agent. When a repo is enabled, Memory also registers an MCP server so an MCP-aware agent can recall and search your history conversationally. For the automatic-vs-explicit details, flags, and how Recall differs from Search, see [Recall vs Search](https://docs.jolli.ai/jolli-memory/recall-vs-search) and [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). ## Share in Jolli When a commit's reasoning would help a teammate, publish it to a dedicated **Jolli Memory Space** your team can read. Sharing needs a **Jolli API Key** (sign-in saves one), so BYOK-only setups cannot share. From the CLI, find your Space and push - the first push binds the repo automatically, so there's no separate bind step: ```bash jolli spaces # list the Spaces you can publish to jolli push --space # binds on first use, then publishes this branch's Memories ``` It sends the summary, commit metadata, changed-file paths, any extracted references (Linear, Jira, GitHub, Notion, Confluence, Asana, monday.com, Slack, Zoom, Vercel, Figma, Sentry, and Context7 library lookups), your repo's remote URL, and any attached plans and notes; it never sends your transcripts or the raw diff. To share a multi-commit story, squash first, then push. **Auto-sync on push:** once a repo is bound to a Space, a `git push` also syncs that branch's Memories to the Space in the background when you're signed in - so you often don't need to run `jolli push` by hand. Turn it off with `jolli configure --set syncOnPush=false`. In the editor extension, the Memory view has a **Push to Jolli** button (**Share in Jolli** in IntelliJ) for the same thing, plus a separate **Share** button for link-based sharing (anyone in your account, anyone with the link, or only people you name). **Heads up:** when you are signed in, clicking **Create PR** in the extension also publishes the branch's Memories to your team in the same step. Once pushed, the Memories appear in that Space in the Jolli web app - that's where your team reads and builds on them. Shared Memories are attributed to you and are removed by deleting the Article from the Space in the web UI; your local copy is untouched. See [Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) for the team-side story. In the web app, the top-level repo folders in a Memory (Vault) space now show a **View knowledge graph** button that opens an interactive, pan-and-zoom view of that repo's knowledge graph. ## Editor extensions (optional) Prefer a visual sidebar to the terminal? There is an extension for VS Code and its forks, and a plugin for JetBrains IDEs. Both are optional - the CLI does everything headless - and both add a sidebar on top of the same stored Memories. For how to install each one, see [Install Jolli Memory](https://docs.jolli.ai/jolli-memory/install-jolli-memory). Enable it by clicking the Jolli Memory icon in the VS Code Activity Bar (or opening the tool window in IntelliJ); hooks install automatically, then reload the window (VS Code) or restart the IDE (IntelliJ) so they take effect. Sign-in and BYOK also have buttons here: **Status overlay → Sign In to Jolli**, or **Settings → AI Summary → Anthropic API Key** (in IntelliJ, **Settings → Tools → Jolli Memory**). OAuth Sign In works in VS Code, Cursor, and Windsurf; if it doesn't complete on your fork, use BYOK or `jolli auth login`. **The sidebar** leads with a segmented **Current Branch / Memory Bank** switch and a `repo / branch` breadcrumb, plus **Settings** (gear) and **Status** (a pulse icon opening a full-pane overlay): - **Current Branch** - three blocks: **Pinned**, **Working Memory** (what is composing for your next commit, with the **Commit Memory** button), and **Committed Memories**. - **Memory Bank** - a cross-branch, cross-repo view of every stored Memory on disk, with search and a Tree / Timeline toggle. See [Memory Bank and Sync](https://docs.jolli.ai/jolli-memory/memory-bank-and-sync). - **Status overlay** - enable/disable, sign-in state, active AI sessions, the summary provider your next commit will use, and any missing-credential warning. For the in-editor actions - **AI Commit**, **Squash**, **Create PR** and the rest - and their CLI equivalents, see [Reference](https://docs.jolli.ai/jolli-memory/reference). **Heads up:** when you are signed in, clicking **Create PR** also publishes the branch's Memories to your team in the same step. ## Next steps - [Reference](https://docs.jolli.ai/jolli-memory/reference) - config keys, commands, and recovery paths. - [Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) - once you've shared a Memory, what the team does with it. - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - every agent and exactly how each session is captured. - [Recall vs Search](https://docs.jolli.ai/jolli-memory/recall-vs-search) - resume one branch, or find a decision across all of them. - [Memory Bank and Sync](https://docs.jolli.ai/jolli-memory/memory-bank-and-sync) - the on-disk copy of your Memories and how it syncs across devices. - [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard) - `jolli dashboard`, a private view of your memories, stats, and standup in your browser. - [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp) - query your history conversationally. - [Jolli Memory in CI and Automation](https://docs.jolli.ai/jolli-memory/jolli-memory-in-ci-and-automation) - run Jolli headless in CI: non-interactive auth, waiting for summaries, and batch backfill. - [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) - first stop when something is not working, plus what data goes where. --- # Install Jolli Memory Source: https://docs.jolli.ai/jolli-memory/install-jolli-memory Jolli Memory runs in more than one place. They all write to the same Memories on your machine, so the choice is about where you work, not about what you get. If you just want the fastest path and you work in a terminal, install the CLI and skip the rest of this page. Everything else here is for picking deliberately. ## Every way in | Where you work | Install | Best for | |---|---|---| | A terminal, Vim, Emacs, or anywhere | [CLI](#cli) | The complete surface. Every command, and the only one that runs in CI. | | VS Code | [VS Code extension](#vs-code-cursor-and-windsurf) | A sidebar and in-editor actions, with the CLI bundled in. | | Cursor, Windsurf, or another VS Code fork | [the same extension, from Open VSX](#vs-code-cursor-and-windsurf) | The sidebar on a fork. | | A JetBrains IDE | [JetBrains plugin](#jetbrains) | The tool window. Needs Node on your `PATH`. | | Claude Code | [Claude Code plugin](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) | Setup handled for you, no npm and no credential. | | Cursor, as your agent | [Cursor plugin](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) | The same, opt-in per repository. | | Codex | [Codex plugin](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) | The same, after you trust its hook. | | Any other MCP-aware agent | [MCP host config](#any-other-mcp-host) | Reading your Memories from the chat, with nothing installed. | | A hosted agent that cannot run local processes | [the hosted endpoint](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp) | Reaching your organization's memory over the web. | | A CI runner | [CLI, headless](https://docs.jolli.ai/jolli-memory/jolli-memory-in-ci-and-automation) | Unattended runs with an API key. | **Node 22.13 or later is required for everything above** except the hosted endpoint. The plugins and the editor extensions bundle Jolli's own code, but none of them bundles Node. You can run more than one. Whichever surface is newest drives a repository's hooks, so they do not fight. ## CLI The primary surface. It works in any terminal, any editor, and in CI. ### Install script (recommended) It installs the CLI, installs Node if you do not have it or your version is too old, then hands off to the guided setup so you finish with Memory already enabled in your repo. **macOS, Linux and WSL** ```bash curl -fsSL https://jolli.ai/install.sh | sh ``` **Windows PowerShell** ```powershell irm https://jolli.ai/install.ps1 | iex ``` **Windows Command Prompt** ``` curl -fsSL https://jolli.ai/install.cmd -o install.cmd && install.cmd && del install.cmd ``` To manage Node yourself, set `JOLLI_INSTALL_NODE=0` before running and the script prints the commands to install Node by hand. On macOS and Linux you can point it at a different Jolli server with `-s -- --url `, or force the Node install with `-s -- --install-node`. **If the script finishes and `jolli` still does not exist, check your Node version first.** The script checks the major version only, so it accepts anything on Node 22 and reports success. The package itself requires 22.13, so `npm` is what refuses, and the script does not show you npm's output on a run it considers successful. Node 22.5 through 22.12 fails this way silently. See [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). ### Or with npm ```bash npm install -g @jolli.ai/cli jolli --version ``` Install it globally, because the git hooks call `jolli` directly. The package refuses to install below Node 22.13, so upgrade first if you need to, for example `nvm install 22.13`. ### Or have your agent install it If you already work in a terminal agent, paste this in: > Install the Jolli Memory CLI: run `npm install -g @jolli.ai/cli`, then `jolli auth login` to sign me > in, then `jolli enable` in this repository and show me `jolli status`. Then continue at [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory). ## VS Code, Cursor and Windsurf One extension covers all of them. It bundles the CLI, so there is no separate install. - **VS Code** (1.101 or later) - Extensions view, search **Jolli Memory**, **Install**. Or `code --install-extension jolli.jollimemory-vscode`. - **Cursor, Windsurf and other forks** - the same extension from Open VSX, for example `cursor --install-extension jolli.jollimemory-vscode`. Enable it by clicking the Jolli Memory icon in the Activity Bar. Hooks install automatically, then reload the window so they take effect. ## JetBrains **Settings → Plugins → Marketplace**, search **Jolli Memory**, **Install**, then restart the IDE. Requires 2025.1 or later. **JetBrains needs Node 22.13 or later on your `PATH`**, and there is no degraded mode below it: the plugin bundles Jolli's code but not Node, so the MCP server and both skills are skipped and the tool window reports it. Memory generation keeps working. ## Agent plugins Jolli ships a plugin for **Claude Code**, **Cursor** and **Codex**. Each fetches itself from that agent's marketplace, so there is no npm step and no credential needed to generate Memories. ``` /plugin marketplace add jolliai/jolli-claude-plugin /plugin install jolli@jolli-marketplace ``` ``` codex plugin marketplace add jolliai/jolli-chatgpt-plugin codex plugin add jolli@jolli-marketplace ``` Cursor has no command form: add `jolliai/jolli-cursor-plugin` as a marketplace, then install **Jolli Memory** from **Customize** in the sidebar. The three differ in ways that matter on your first day, including one that surprises everyone: Cursor does not set up a repository until you opt it in. For the install details, the differences, and what to check when nothing appears to happen, see [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). ## Any other MCP host Eleven hosts are configured for you when you run `jolli enable`. For anything else, `jollimemory` is a standard stdio MCP server, so any MCP-capable host can use it. **With nothing installed**, point the host at: ``` npx -y @jolli.ai/cli mcp ``` That gives the agent read access to Memories you already have. Recording new ones still needs `jolli` enabled in the repo, because capture runs off git hooks. **With the CLI installed**, register a stdio server with command `jolli` and args `["mcp"]`, under whatever key that host uses. Hosts differ in where they keep MCP configuration and in which parts of the protocol they support. Check your host's own documentation for the file it reads. For the eleven that are wired up automatically, and for connecting an agent that cannot start a local process, see [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). ## Which one should I use? Most people should take the CLI, or the plugin for the agent they already live in. The cases below are the ones where the answer is genuinely not obvious. **You work in Cursor.** Three different things carry the name, and they do different jobs: - The **Cursor plugin** is the one you want if Cursor is your coding agent. It sets up repositories you opt in, gives you `/jolli-` skills, and briefs each new session. - The **VS Code extension** from Open VSX gives you the visual sidebar. Install it as well if you want the panel; it is not an alternative to the plugin. - **Cursor as an MCP host** happens on its own when you run `jolli enable` with the CLI. You do not choose this one. **You work in VS Code or Windsurf.** Take the extension. There is no agent plugin for either. **You already have the CLI and you want a plugin too.** Fine, and common. Whichever surface is newest drives the repository's hooks. **You only want to read Memories, not record them.** Use the `npx` MCP server above. Nothing is installed and nothing is written to your repositories. **You are setting up a CI runner.** Use the CLI with an API key, not the install script. See [Jolli Memory in CI and Automation](https://docs.jolli.ai/jolli-memory/jolli-memory-in-ci-and-automation). ## What differs by surface Everything above records the same Memories. These are the differences worth knowing before you pick. | I want to... | Best surface | |---|---| | Run Memory anywhere, including CI | CLI | | Get a briefing at the start of every AI session, without asking | Claude Code, Cursor or Codex plugin | | Browse Memories in a sidebar while I code | VS Code extension, or the JetBrains plugin | | Set it up without installing npm or adding a credential | An agent plugin | | Keep my repositories untouched until I say so | Cursor plugin | | Ask about my history in plain language | Any MCP host | | Reach my team's memory from a hosted agent | The hosted endpoint | | See stats, standup and the knowledge graph | CLI, via [the local dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard) | | Publish Memories to my team | Any surface, once you sign in | | Feed [The Web Dashboard](https://docs.jolli.ai/jolli-memory/the-web-dashboard) with session statistics | CLI, the VS Code extension, or any of the three agent plugins | **The surfaces do not all carry the same CLI version.** Each agent plugin bundles its own copy, and the JetBrains plugin ships on its own schedule, so either can sit a release behind npm. That only matters for features that arrive in the engine rather than in the surface: session statistics, which fill the web dashboard, need the CLI at 0.99.14 or later. Every surface now clears that floor, so a setup on any one of them sends session statistics. Check what you have with `jolli --version`, or install the CLI alongside your plugin if you want the newest engine as soon as it ships. The `jolli space`, `jolli site` and `jolli workflow` command families are separate npm packages and are not carried by any plugin or extension. Install them alongside the CLI, for example `npm i -g @jolli.ai/cli @jolli.ai/space-cli`. ## Next steps - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - sign in, enable your repo, and your first Memory. - [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) - the three agent plugins in depth. - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - every agent Memory captures from, and how. - [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp) - the MCP tools and the hosted endpoint. - [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) - first stop when an install does not take. - [Welcome to Jolli](https://docs.jolli.ai/welcome-to-jolli) - Memory, Spaces and Sites together. --- # Jolli Memory in CI and Automation Source: https://docs.jolli.ai/jolli-memory/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: ```bash 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 ```bash 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: ```bash 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: ```bash jolli spaces # find your Space id or slug jolli push --space ``` 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: ```bash 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 ` controls how loosely a transcript is matched to a commit. ## Environment variables | Variable | What it does | |---|---| | `ANTHROPIC_API_KEY` | BYOK LLM credential; Memory calls Anthropic directly. | | `JOLLI_AUTH_TOKEN` | OAuth-token override for account identity (not a summary credential). | | `JOLLI_URL` | Override the Jolli server origin (allowlisted, HTTPS-only). | | `JOLLI_NO_PLUGINS` | Set to `1` to disable plugin discovery. It turns off every plugin, so the Space, Site **and Workflow** commands all go with it. | | `XDG_DATA_HOME` | Base dir for OpenCode's session database. Default `~/.local/share`. | | `DO_NOT_TRACK` | Set 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.) ## 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: ```bash 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`: ```bash # Which Workflows can run locally on this machine right now? jolli workflow local-run # A Workflow's run history, newest first jolli workflow runs # Block until a run reaches a final state, then print its report jolli workflow run-status ``` `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](https://docs.jolli.ai/jolli-memory/reference). ## Other automation notes - **Target a specific repo** with `--cwd ` 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: ```yaml - 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](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. - [Reference](https://docs.jolli.ai/jolli-memory/reference) - every config key, command, and flag. - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - how sessions are captured, and the diff-only fallback. --- # Jolli Memory in Your AI Agent Source: https://docs.jolli.ai/jolli-memory/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. **Then quit Cursor completely and reopen it.** Cursor does not register a freshly installed plugin's hooks until a full restart, and reloading the window or starting another chat is not enough. The skills are all there either way, but until that restart the bootstrap has not written the dispatcher they fall back on, and `/jolli` will tell you so and ask you to do exactly this. 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** - 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: | In Customize | Where it came from | Use it? | |---|---|---| | **Jolli Cursor** | this plugin, added by you | **Yes** | | **Jolli Marketplace** | your Claude Code setup, imported automatically | No | Install from the one with **Cursor** in its name. Both offer a card reading **Jolli Memory**, so the marketplace title above the card is the only thing telling them apart. If you are unsure which one you installed, check where it landed: this plugin caches under `~/.cursor/plugins/cache/jolli-cursor/`, the imported Claude Code one under `~/.cursor/plugins/cache/jolli-marketplace/`. 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:** its hook and its MCP server both resolve the wrong directory under Cursor, so 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: ```bash 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 | | Claude Code | Cursor | Codex | |---|---|---|---| | Skill prefix | `/jolli:recall` | `/jolli-recall` | `$jolli:recall` | | Sets up a repository on its own | Yes, every session | **No** - you opt each repository in | Yes, every session | | Session-start briefing | Yes | Yes, once the repository is set up | Yes | | Extra approval step | None | None | **Trust the hook in `/hooks`** | | MCP tools available from | Your first session | **After you opt the repository in**, then one click to enable | Your **second** session | 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. All three now record a session as each turn ends, so nothing waits for a commit to be noticed. On Cursor that is newer than the rest: earlier versions of the plugin found a Cursor session only when you committed, which meant work you had not committed yet, or a session you never returned to, could be missed. **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 — ]` 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](https://docs.jolli.ai/jolli-memory/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](https://docs.jolli.ai/jolli-memory/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. | Cause | What to do | |---|---| | The agent was not fully restarted | Setup runs at session start. Quit the app completely and reopen it. To check whether setup has run at all, look for the file `~/.jolli/jollimemory/run-cli`; if it is missing, the plugin has not set itself up yet. | | The session is not inside a git repository | The plugin only acts inside a git repository and does nothing at all outside one. Open a folder that is a repository, or run `git init` first. | | **On Cursor:** the repository was never opted in | Expected, not a fault. Run `/jolli` or `/jolli-init` in that repository. | | **On Codex:** the hook is not trusted yet | Open `/hooks`, trust the `SessionStart` entry, start a new session. Re-check this after every plugin upgrade. | | Memory was turned off for this repository earlier | Turning Jolli off is remembered, and the plugin honors it: it keeps Memory off and removes that repository's hooks even after you install the plugin. The setting lives in `.jolli/jollimemory/profile.json` in the repository's main worktree, and in a repository with submodules turning it off in one covers the others. Turn it back on and the plugin sets up on the next session - see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). | 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 =true`. For everything else - missing credentials, a stuck background worker, a summary that never generated - see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/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. | Action | What it does | |---|---| | `status` | Show Memory's setup and configuration health for this repository. Start here when something looks wrong. | | `init` | One-shot setup: sign in if needed, confirm the repository is enabled, and bind it to a Jolli Space. | | `login` / `logout` | Sign in to Jolli in your browser, or sign out. Any Anthropic API key you have set is left in place. | | `timeline ` | Show how a decision topic evolved over time, oldest first. | | `recall` | Load a branch's past reasoning and answer questions about it. Use it to resume work. | | `search` | Search decisions across every branch. Use it to find where something was decided. | | `push` | Publish this branch's memories to a Jolli Space so teammates can see them. | | `dashboard` | Open the local dashboard in your browser: memories, agent sessions, token spend and knowledge across every repository on the machine. Say "url only" if you want the address instead of a browser window. | 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. **On Cursor, every skill now ships with the plugin.** All twelve are there from the moment you install, including `recall` and `search`, which previously appeared only after you had opted a repository in. Setting a repository up is still what gives them something to read, but it is no longer what makes them appear. One side effect is worth knowing. Cursor pools every skill source into one flat menu and cannot merge them, so in a repository that is also set up for Claude Code or Codex, four of these - `recall`, `search`, `local-run`, `remote-run` - are listed **twice**: once from this plugin, once from the cross-platform copy those tools read. The two are the same instructions, and either entry works. `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)](https://docs.jolli.ai/jolli-memory/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](https://docs.jolli.ai/jolli-memory/getting-started-with-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](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture). ## Next steps - [Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory - [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp) - the MCP tools - [Recall vs Search](https://docs.jolli.ai/jolli-memory/recall-vs-search) - when to use which - [Reference](https://docs.jolli.ai/jolli-memory/reference) - every CLI command and configuration key - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - how each agent is captured - [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) - when something is not working --- # Memory Bank and Sync Source: https://docs.jolli.ai/jolli-memory/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// ``` 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///-.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-`, 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=` 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 () 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: ```bash 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: ```bash jolli cutover --status ``` And afterwards, you can confirm the frozen branch is genuinely at rest: ```bash 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: | Where you run it | Sync behavior | | --- | --- | | JetBrains plugin | Automatic. Once you are signed in, IntelliJ syncs your Memory Bank to your Personal Space in the background by default. Background sync runs on a poll timer set by the Poll interval (seconds) field on the Sync to Jolli tab, which defaults to 90 minutes (shorter values are raised to the 90-minute minimum). You can turn auto-sync off with the Auto-sync to Personal Space checkbox on that tab, and still sync by hand. | | VS Code extension | Manual by default. There is no toggle for background sync; click Sync to Personal Space Now when you want a sync. | | CLI | Manual. Run `jolli sync-memory-bank` when you want a sync. The CLI never syncs on its own. | 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. | | Sync | Share in Jolli | | --- | --- | --- | | What it is for | Mirror your memories across your own devices | Publish one memory to your team | | What it sends | Your whole Memory Bank: summaries, plans, and notes. Transcripts only if you opt in | One commit's summary plus its attached plans, notes, references, and skills | | Who can see it | Only you, in your private Personal Space | Your team, in a shared Jolli Space | | Raw transcripts | Only if you turn on `syncTranscripts` | Never sent | | The git diff | Never sent | Never sent | | How it runs | Automatic in IntelliJ, manual in VS Code and the CLI | Manual, one memory at a time | | Needs a Jolli API key | Yes | Yes | | To undo | Re-sync, or delete from your Personal Space | Delete the article in the Jolli web UI. Your local copy is untouched | 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](https://docs.jolli.ai/jolli-memory/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](https://docs.jolli.ai/jolli-memory/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: ```bash 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](https://docs.jolli.ai/jolli-memory/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](https://docs.jolli.ai/jolli-memory/reference). ## Related - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. - [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard) - browse the same memories in your browser with `jolli dashboard`. - [Reference](https://docs.jolli.ai/jolli-memory/reference) - config keys, including `localFolder` and `syncTranscripts`. - [Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) - the team-side story once you publish a Memory. --- # Recall vs Search Source: https://docs.jolli.ai/jolli-memory/recall-vs-search ## Overview Recall resumes one branch. Search finds a decision across all branches. Both feed old context back to you, so people mix them up. They do different jobs. > **If you only remember one thing:** Recall pulls one branch's full history into your next AI session so you can keep going where you left off. Search scans every branch for a decision, topic, or commit when you do not remember where it lives. ## Prerequisites - The `jolli` CLI installed and Memory enabled in the repository. - Memories already generated **on this machine** - Recall reads your own disk, not the server. - On Cursor and Codex, the automatic session-start briefing needs the Jolli plugin for that agent. ## Recall: resume one branch Recall compiles everything Memory knows about a single branch - its commit summaries, the decisions behind them, attached plans and notes, and file-change stats - into a briefing for your AI agent. One branch, full depth. Use it to continue your own work after a break. > **Recall reads your own machine.** It compiles from the memories stored with your local clone, so it can only recall a branch whose memories were generated on this machine. A teammate's branch is not in your store, even if you have checked their branch out: memories are kept on local-only git refs and are never pushed to your remote alongside the code. To read a colleague's reasoning, use the shared Jolli Space they published to - see [Reading a teammate's work](#reading-a-teammates-work) below. ### Automatic vs explicit **Automatic, in Claude Code, Cursor, and Codex.** When you start a session in a repo with Memories, a compact `[Jolli Memory — ]` block (about 300 to 500 tokens) prepends the conversation: branch name, recent Memories, key decisions, and pinned plans. It is small enough not to eat your context budget. On any day after your last commit the briefing adds a tip to run a full Recall; once more than three days have passed it escalates that to a warning naming the number of days. Claude Code gets this from the CLI alone. Cursor and Codex get it once you install the Jolli plugin for that agent - see [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). The automatic briefing runs on feature branches only. It is skipped on the shared branches `main`, `master`, `develop`, `development`, `staging`, and `production` (an exact, case-sensitive match, so a branch named `Main` or `release/2.0` still gets one). Skipping the automatic briefing does not disable recall: you can always pull any branch's context on demand with `jolli recall ` (for example `jolli recall main`). Every other agent, and these three without a plugin, pulls context manually instead of getting the automatic briefing. **Explicit, any agent.** Inside Claude Code, run `/jolli:recall` (or `/jolli:recall `) for a deeper pull. In Codex, Gemini CLI, OpenCode, Cursor, and Copilot the same skill is `/jolli-recall`. From the CLI: ```bash jolli recall ``` With no argument, Recall uses your current git branch. Pass a branch name to recall a different one. If the name does not match a recorded branch, Recall lists the branches it has. (`jolli recall` is also available under the alias `jolli context`.) ### Short summary vs full context A bare `jolli recall` prints a short, human-readable summary for the terminal: last commit, topic counts, a few key decisions, files changed. That is a digest, not the full context. To get the full context (the version worth feeding to an AI agent), add a flag: ```bash jolli recall --full # full markdown to your terminal jolli recall --format json # structured payload for a skill or agent jolli recall --output ctx.md # full markdown written to a file ``` ### Useful flags The everyday ones: `--full` (full context instead of the short summary), `--budget ` (default 20,000; raise it when a long branch truncates, since lower-priority fields are trimmed first), and `--format ` (JSON for a skill or agent). See [Reference](https://docs.jolli.ai/jolli-memory/reference) for the complete set: `--depth`, `--output`, `--include-transcripts`, `--no-plans`, and `--catalog`. ## Search: find a decision across branches Search runs a full-text, relevance-ranked query over your distilled commit summaries across every branch recorded on this machine. It returns lightweight hits, each with a title, a short snippet, the branch it belongs to, and the commit. It does not return the full decision text per hit - it points you to where the answer lives. From the CLI: ```bash jolli search "why did we switch to JWT" ``` Reach for Search when you are asking "have we handled X before", "why did we choose X over Y", or "which commit touched that half-remembered ticket or file". ### Useful flags The common ones: `--limit ` (default 20, max 100), `--branch `, `--type `, and `--format ` (default `json`). See [Reference](https://docs.jolli.ai/jolli-memory/reference) for the full set. > **Tip:** `jolli search` prints JSON by default. For a quick terminal read, add `--format text` for a one-line-per-hit view. ### Then recall the hit's branch for depth Search hits are intentionally shallow. When a hit looks right, run Recall on that hit's branch to load the full rationale and decisions: ```bash jolli recall ``` Search finds the branch. Recall gives you its full story. ## Which one do I want? | I want to... | Use | Why | | --------------------------------------------------- | ------------------------------- | -------------------------------------------------------------- | | Continue a branch I was working on | Recall | Loads that one branch's full history into your AI session. | | Understand a teammate's branch | Their Jolli Space | Recall and Search only read memories generated on your own machine. | | Remember why we chose X over Y | Search | Finds the decision wherever it was made. | | Find the commit for a half-remembered ticket or file | Search | Ranked hits across every branch. | | Read the full rationale behind a search hit | Recall the hit's branch | Search hits are lightweight; decisions live in Recall. | Rule of thumb: you know the branch, use Recall. You are hunting a topic, use Search. ## Reading a teammate's work Both Recall and Search read the memories stored with your own clone, so neither reaches work done on someone else's machine. Checking out their branch does not help: the memories live on git refs Jolli keeps local, and pushing your code never pushes them. What crosses between people is a **Jolli Space**. When a teammate shares a memory or pushes a branch to a Space, it becomes readable there: - In the Jolli web app, in the Space their repository is bound to. - From your AI agent, using the hosted memory tools over MCP, which search your organization's memory rather than your local store. See [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). So the split is worth holding onto: Recall and Search answer "what did *I* do here", and the Space answers "what did *we* decide". If a teammate's branch is not showing up for you, the question is whether it was ever pushed to a Space, not which flag to pass to Recall. ## Commands, by where you run them | Where you run it | Recall | Search | | ---------------------------- | -------------------------------------------------------------- | ------------------------------------------ | | Claude Code | Automatic briefing at session start; `/jolli:recall [branch]` for depth. | `/jolli:search `. | | Cursor, Codex (with the Jolli plugin) | Automatic briefing at session start; `/jolli-recall` in Cursor, `$jolli:recall` in Codex, for depth. | `/jolli-search` in Cursor, `$jolli:search` in Codex. | | Gemini, OpenCode, and Codex or Cursor without the plugin | No auto briefing; run the `/jolli-recall` skill. | `/jolli-search` where the skill is installed. | | CLI | `jolli recall` (short) or `jolli recall --full` (full). | `jolli search `. | | VS Code extension | "Recall in Claude Code" button, or "Copy recall prompt" to paste into any AI tool. | See the callout below. The sidebar box is a filter. | | JetBrains plugin | Recall menu copies a prompt for your AI coding tool. | See the callout below. The sidebar box is a filter. | | Jolli in your browser | A Memory summary's panel has a **Copy Recall Prompt** button that copies a ready-to-paste recall prompt for your AI agent. | n/a | | AI agents (MCP) | `recall` tool (defaults to the current branch). | `search` tool. | ## The sidebar "Search Memories" box is a filter, not full-text Search This is the most common mix-up. > **The "Search Memories" box in the VS Code and IntelliJ sidebar is not `jolli search`.** It is a case-insensitive substring filter over the Memories list. In VS Code and its forks (Cursor, Windsurf) it matches on **commit message, branch name, and repo name**; in IntelliJ it matches on **commit message, branch name, repo name, and file path**, and only in the Timeline view. Either way it does not read inside the Why, Decisions, or Implementation text, and it does not use the full-text ranking that `jolli search` does. So if you type a decision detail into the sidebar box and get nothing, that is expected. The box narrows the visible list of stored Memories; it does not search their contents. To search decision and topic text across branches, use one of these instead: - `jolli search ""` from the CLI. - `/jolli:search ` in Claude Code, or `/jolli-search ` in another agent with the skill. - The `search` MCP tool, if your agent is wired to Memory over MCP. ## Related - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. - [Reference](https://docs.jolli.ai/jolli-memory/reference) - the full recall and search flag lists, and config keys. - [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp) - run recall and search conversationally, no CLI. --- # Reference Source: https://docs.jolli.ai/jolli-memory/reference ## Overview The lookup surface for Jolli Memory. Configuration first, then every CLI command, then the agent support matrix. To fix a problem, see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). ## Prerequisites - The `jolli` CLI installed, on **Node 22.13 or later**. - The `jolli space`, `jolli site`, and `jolli workflow` command families each need their own plugin package, noted at the section that documents them. ## Configuration All configuration lives in `~/.jolli/jollimemory/config.json`. The CLI, VS Code (including forks such as Cursor and Windsurf), and IntelliJ read from the same file. Secrets (`apiKey`, `jolliApiKey`, `authToken`) are masked when displayed. ### Keys | Key | Type | Description | Default | |---|---|---|---| | `apiKey` | string | Anthropic API key (BYOK). Resolution order: config `apiKey`, then `ANTHROPIC_API_KEY`, then the Jolli proxy via `jolliApiKey`. | none | | `aiProvider` | enum (`anthropic`, `jolli`, `local-agent`) | Pins which backend generates summaries: `anthropic` (BYOK), `jolli` (proxy), or `local-agent` (drive a locally-installed agent CLI, no key - pick which one with `localAgentTool`). When unset, the resolver uses the order above. Set to `jolli` automatically when you sign in. | auto | | `model` | string | Model for summarization. Accepts an alias (`sonnet`, `haiku`, `opus`) or a full Anthropic model ID. | `sonnet` (resolves to `claude-sonnet-4-6`) | | `maxTokens` | number | Max output tokens per summarization call. | `8192` | | `jolliApiKey` | string | Jolli API key (`sk-jol-...`). Powers sign-in, the LLM proxy, and cloud features. | none | | `authToken` | string | OAuth token from `jolli auth login`. | none | | `claudeEnabled` | boolean | Enable Claude Code session tracking. | `true` | | `codexEnabled` | boolean | Enable Codex CLI session discovery. | auto | | `geminiEnabled` | boolean | Enable Gemini CLI session tracking. | auto | | `openCodeEnabled` | boolean | Enable OpenCode session discovery. Requires Node 22.13+. | auto | | `cursorEnabled` | boolean | Enable Cursor session discovery: the Composer IDE and the `cursor-agent` CLI. One shared switch. The Composer IDE path requires Node 22.13+ (SQLite); the CLI path reads plain files and has no Node requirement. | auto | | `copilotEnabled` | boolean | Enable GitHub Copilot CLI and VS Code Copilot Chat discovery. One shared switch. The Copilot CLI path requires Node 22.13+ (SQLite); the Copilot Chat path reads plain files and has no Node requirement. | auto | | `clineEnabled` | boolean | Enable Cline session discovery: the VS Code extension and the Cline CLI. One shared switch. Both read plain files - no Node requirement. | auto | | `devinEnabled` | boolean | Enable Devin CLI session discovery. Requires Node 22.13+ (SQLite). | auto | | `antigravityEnabled` | boolean | Enable Antigravity session discovery. Requires Node 22.13+ (SQLite). | auto | | `kimiEnabled` | boolean | Enable Kimi Code CLI session discovery. Reads plain files - no Node requirement. | auto | | `hermesEnabled` | boolean | Enable Hermes Agent (`~/.hermes`) session discovery. Requires Node 22.13+ (SQLite). | auto | | `globalInstructions` | enum (`enabled`, `disabled`) | Whether Jolli may write its skill-preference block into your machine-global AI instruction files; applied immediately when you set it. Unset means undecided. | unset | | `logLevel` | enum | `debug`, `info`, `warn`, `error`. | `info` | | `excludePatterns` | string[] | Globs for files to exclude from the Changes panel. | none | | `localFolder` | string | Memory Bank root on disk. Every memory is dual-written here. Set it via the CLI or the editor Memory Bank settings. | none | | `commitFeedback` | `auto`, `on`, `off` | Whether the post-commit hook prints capture progress inline and waits for it to finish. `auto` shows it only in an interactive place, so GUI git clients stay silent and fast. | `auto` | | `dashboardKnowledgeMenuEnabled` | boolean | Whether `jolli dashboard` shows the **Knowledge** sidebar row. The row only: `/knowledge` stays reachable by URL either way. | off | | `dashboardGraphMenuEnabled` | boolean | Whether `jolli dashboard` shows the **Graph** sidebar row. Same scope: `/graph` stays reachable either way. | off | | `openUrlAllowedOrigins` | list of strings | Extra origins `jolli open-url` is allowed to open. | none | | `backupFolder` | string | Where snapshots of the local database are written. Validated when you save it, not when you set it. | `~/jolli_back` | | `backupRetentionDays` | number | How long to keep those snapshots. Must be a whole number of 1 or more. | `20` | | `syncTranscripts` | boolean | Include raw transcripts in cloud sync, not just summaries. | `false` | | `syncPollIntervalSec` | number | Auto-sync poll interval in seconds (IntelliJ auto-sync). Range 5400 to 86400. | `5400` (90 min) | | `syncOnPush` | boolean | Auto-sync a branch's Memories to its bound Jolli Space on every `git push` (via the pre-push hook). | on when signed in | | `syncSessions` | boolean | Upload session statistics (tokens, cost, tool names, session titles) to your Jolli organization. Unlike the two rows above it, this covers **every repository Jolli is enabled in on the machine**, bound to a Space or not. See [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). | on when signed in | | `mcpPlatformToolsEnabled` | boolean | Register backend-defined Jolli-platform tools in the MCP server, alongside the built-in memory tools. Set `false` for a git-memory-only server. | on | | `wikiRebuild` | enum (`auto`, `manual`) | When the knowledge wiki and graph rebuild. Left unset they rebuild only when you ask, so commits stay fast and no AI credits are spent unprompted. Set `auto` to rebuild after every commit. | manual (unset) | | `localAgentTool` | enum (`claude-code`, `codex`, `cursor-agent`, `opencode`, `kimi`, `hermes`) | Which local agent CLI to drive when `aiProvider=local-agent`. See [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) for how to sign in to each one. Left unset, Jolli drives Claude Code - set this key explicitly if you installed a different agent. | `claude-code` | | `localAgentModel` | enum, per tool | Which model the local agent is told to run. Only `claude-code` (`haiku`, `sonnet`, `opus`) and `codex` (`gpt-5.6-luna`, `gpt-5.6-terra`, `gpt-5.6-sol`, `gpt-5.5`) accept one; the other tools run whatever they are configured with. Each tool keeps its own value, so switching `localAgentTool` does not carry a model across. `inherit` opts back out and runs the tool's own setting. A value the tool in force does not offer falls back to that tool's default. Run `jolli configure --help` for the current list, since the Codex ids are dated and retire. | `sonnet` (claude-code), `gpt-5.6-terra` (codex) | | `localAgentPath` | string | Explicit path to the local agent binary, overriding PATH discovery. Only used when `aiProvider=local-agent`. | none | | `slack.workspaceUrl` | string | Slack workspace URL (`https://.slack.com`) - fallback for Slack thread permalinks in references. Set it with `jolli configure --set slack.workspaceUrl=`; there is no editor field for it. An existing value keeps working and is never overwritten. | none | | `telemetry` | enum (`on`, `off`) | Content-free usage telemetry (attributable to your account only when signed in). Set it with the `jolli telemetry on\|off` command, not `jolli configure` (it is not an accepted `configure` key). | `on` | A few advanced keys are edited by hand in `config.json` and are not accepted by `jolli configure`: `logLevelOverrides`, `compileExcludeFolders`, `dcoSignoff`, `storageMode`, and `syncConflictPolicy`. `storageMode` selects where memories are written - `dual-write` (default: orphan branch + on-disk folder), `folder` (folder only), or `orphan` (orphan branch only, no browsable Markdown on disk). `syncConflictPolicy` sets the fallback when a sync conflict cannot be auto-merged - `prompt` (default), `mine` (always keep the local side), or `theirs` (always accept the other device). ### Editing config from the CLI ```bash jolli configure # show current config (secrets masked) jolli configure --list-keys # list every key with its type jolli configure --set model=sonnet --set maxTokens=16000 jolli configure --set excludePatterns=docs/**,*.log jolli configure --remove apiKey ``` Unknown keys and malformed values are rejected with exit code 1. ### Environment variables | Variable | What it does | |---|---| | `ANTHROPIC_API_KEY` | Fallback for Anthropic direct calls when no `apiKey` is set. | | `JOLLI_AUTH_TOKEN` | Read-time OAuth-token override for CI and scripts. | | `ANTHROPIC_BASE_URL` | Override the Anthropic API base URL (used by the official SDK). Default `https://api.anthropic.com`. | | `XDG_DATA_HOME` | Base directory for OpenCode's `opencode/opencode.db`. Default `~/.local/share`. | | `DO_NOT_TRACK` | Opt out of usage telemetry: set to any non-empty value other than `0` (e.g. `1`). | | `JOLLI_NO_PLUGINS` | Set to `1` to disable plugin discovery. It turns off every plugin, so the Space, Site and Workflow commands all go with it. | | `JOLLI_COMMIT_FEEDBACK` | Overrides `commitFeedback` for one invocation. | | `JOLLI_MCP_PLATFORM_TOOLS` | Overrides `mcpPlatformToolsEnabled` for one invocation. | | `JOLLI_OPEN_URL_ALLOWED_ORIGINS` | Overrides `openUrlAllowedOrigins` for one invocation. | ## CLI commands Binary `jolli`, package `@jolli.ai/cli`. Most commands accept `--cwd ` to run against a specific repo root. ### Core | Command | What it does | Key flags | |---|---|---| | `jolli enable` | Install git hooks, agent hooks, the MCP server, and the recall skill. | `-y`, `--integrations-only`, `--repo-hooks-only`, `--cwd` | | `jolli disable` | Remove all hooks. Stored memories are untouched. | `--cwd` | | `jolli uninstall` | Remove Jolli Memory's installation and configuration machine-wide: editor integrations, the global `@jolli.ai/cli` package, the `.jolli/jollimemory/` state directories, and this repo's hooks. Your stored memories are never touched. | `--dry-run`, `-y`, `--scope ` (default `all`) | | `jolli status` | Show installation, credential, and session state. | `--json`, `--refresh` | | `jolli view` | View memories. Compact list by default; full detail with `--commit`. | `--count ` (default 10), `--commit `, `--output `, `--format ` | | `jolli recall` | Compile branch context for an AI session. See flags below. | `--full`, `--budget`, `--catalog`, `--format` | | `jolli search` | Search memories across every branch with BM25 ranking, in a single pass. | `--limit` (default 20, max 100), `--branch`, `--type `, `--format `, `--output ` | | `jolli export` | Export memories as Markdown to `~/Documents/jollimemory//` (a manual one-off dump, separate from the auto-maintained Memory Bank at `~/Documents/jolli//`). | `--commit `, `--project ` | | `jolli configure` | Manage config keys. See above. | `--set`, `--remove`, `--list-keys` | | `jolli doctor` | Diagnose installation health. `--fix` releases stale locks, reinstalls missing hooks, removes stale dist-path entries, takes an overdue database snapshot, and un-parks stuck dashboard events; adding `--forget-dead` also drops registry entries whose folder is gone, which deletes those repositories' memories. `--schema-log` prints your memory database's migration log; `--mark-migration` records one migration as applied by other means, for repairing a missing record. `--sync-sessions` uploads whatever session statistics are waiting, ignoring the usual throttle. It also reports memory trees stranded by a rewritten commit, which `jolli repair-memory` fixes. | `--fix`, `--schema-log`, `--mark-migration `, `--sync-sessions` | | `jolli repair-memory` | Reattach memory trees stranded by an amend, rebase or squash, when the memory stayed on the old commit hash. `--status` previews without changing anything. Safe to run twice, and it backs up whatever it replaces. Refuses to run in a repository turned off with `jolli disable` (except `--status`). | `--status`, `--from `, `--to `, `--no-llm`, `--cwd ` | | `jolli clean` | Remove expired state (stale sessions, old queue entries, stale squash markers). Stored memories and transcripts are never deleted. | `--dry-run`, `-y` | | `jolli dashboard` | Serve the local Jolli dashboard in your browser until you stop it with Ctrl+C. | `--port ` (default 1818, then 18118), `--no-open`, `--cwd ` | `jolli enable --repo-hooks-only` installs only the repo hooks, the Claude agent hooks, and the project `/jolli` menu - it skips host detection and MCP registration, and backs the Claude Code plugin bootstrap. It is mutually exclusive with `--integrations-only`, which repairs the MCP server, skills, and dispatch scripts without changing repo hooks. `jolli view --commit ` accepts a numeric index (`1` is the latest) or a commit SHA prefix. HEAD, branch names, and tags are not recognized (they resolve to nothing). `jolli status --refresh` re-checks which Jolli Space this repo is bound to by asking the server, instead of trusting the locally cached answer. Reach for it when the binding shown looks out of date. `jolli dashboard` serves a dashboard from your own machine and holds the terminal until you press Ctrl+C. The pages are served locally and need no account. For the pages it serves, what each one shows, and how the repository picker works, see [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). Statistics from the database behind it are uploaded to your organization when you are signed in, which `syncSessions` controls - see the config table above. ### `jolli recall` flags `--full` (full markdown instead of the short summary), `--output ` (implies `--full`), `--depth `, `--budget ` (default 20,000), `--include-transcripts`, `--no-plans`, `--catalog` (list recorded branches), `--format `. Pass a branch name or keyword as an argument, or omit it for the current branch. ### Auth & cloud | Command | What it does | Key flags | |---|---|---| | `jolli auth login` | Sign in via browser OAuth and save a Jolli API key. | | | `jolli auth logout` | Remove the Jolli auth token and API key. Your Anthropic key is preserved. | | | `jolli auth status` | Show sign-in state. | | | `jolli sync-memory-bank` | Run one Memory Bank cloud sync round. Needs a Jolli sign-in. | `--transcripts`, `--cwd` | | `jolli push` | Push this branch's memories to a bound Jolli Space. | `--base`, `--space`, `--format json` | | `jolli spaces` | List the Jolli Spaces you can bind to. | `--format json` | | `jolli bind` | Bind this repo to a Jolli Space. | `--space` (required), `--repo-name` | | `jolli push-control` | Show or set whether this repo's memories are pushed to a Jolli Space. Run it with no flags to see where the repo stands. | `--enable`, `--disable`, `--format json`, `--cwd` | `jolli push-control --disable` stops this repo from sending memories to a Space. Memories are still recorded locally, so nothing is lost; only the outbound push is off. `--enable` turns it back on and kicks off a catch-up so the memories held while it was off are sent. `--enable` and `--disable` cannot be combined. The choice is stored once per repository, machine-wide, keyed by the repo's remote URL rather than inside the working tree. Two consequences: every worktree of the same repo shares one setting, and a repo with no remote cannot be listed alongside the others because there is no identity to key it by (you can still control it from inside the repo with `--cwd`). If that stored setting cannot be read, Jolli reports pushing as OFF rather than guessing, and says why. Repair the file if you can. `--enable` will rebuild it, but a rebuild starts from an empty set, so every other repo's opt-out on that machine is turned back on. Pushing can be stopped by more than this one setting: a repo turned off with `jolli disable` does not push either, and `syncOnPush: false` separately stops the automatic push on `git push`. All of them retain the pending memories rather than dropping them. Memory Bank cloud sync is on-demand. Run it from the CLI with `jolli sync-memory-bank`, or from the VS Code Settings page. IntelliJ can also sync automatically on a schedule, controlled by its Settings toggle. The only precondition is a valid `jolliApiKey`. In a terminal, `jolli sync-memory-bank` prompts you to resolve each conflict (mine / theirs / view diff / skip); only in a non-interactive shell (a hook or CI) does it skip conflicting files and print their paths for you to resolve in your editor. To publish memories to a team Jolli Space, run `jolli bind` once, then `jolli push`. The VS Code and IntelliJ editors offer the same publish per memory through the Share in Jolli action. ### Knowledge & maintenance | Command | What it does | Key flags | |---|---|---| | `jolli compile` | Fold commit memories into per-topic wiki pages. Runs only when you ask, unless you set `wikiRebuild` to `auto`. | `--rebuild` (requires `--cwd`), `--cwd` | | `jolli graph` | Export the knowledge graph to a self-contained HTML file. | `--export `, `--open`, `--cwd` | | `jolli heal-folder` | Re-render missing Markdown in the Memory Bank folder from the canonical JSON. No LLM call. | `--cwd` | | `jolli backfill` | Create memories for commits made before you enabled Jolli. Claude transcripts only. | `--last ` (default 20), `--all`, `--hashes ` (specific commits, comma-separated; overrides `--last`/`--all`), `--dry-run`, `--min-confidence ` (default low), `--format `, `--stream`, `--list-candidates` | | `jolli cutover` | Make SQLite this repo's source of truth (freeze the orphan branch). One way - see below. | `--status`, `--probe`, `--cwd ` | `jolli compile` requires an API key, the same one used for summary generation - which is why it stays manual unless you opt in: with `wikiRebuild` set to `auto` it also runs after each commit and after a merge or pull, and each of those runs is billed. `jolli graph` needs no key - it only exports the existing knowledge graph (`.jolli/graph/graph.json`, produced by a prior `jolli compile`) to HTML, and errors telling you to run `jolli compile` first if that graph is missing. `jolli cutover` switches one repository's memory storage from the git orphan branch to a local SQLite database, which then becomes the source of truth. **It is one way.** The cutover freezes the repository's orphan branch, and `jolli enable` will not unfreeze it, so run `jolli cutover --status` first to see where the repository stands before committing to it. After a cutover, `jolli cutover --probe` checks the frozen branch for drift - it should not be moving, and a probe that reports it is means something is still writing to it. Restart any IDE or long-running process afterwards so cached storage handles are rebuilt. Memory Bank and Sync covers what this changes day to day. Two backfill flags are for scripting rather than day-to-day use. `--stream` emits one NDJSON progress event per commit and then a final report line, so a script can follow a long run. `--list-candidates` reports which commits could be back-filled as JSON and exits without attributing anything or calling the LLM; `--since-days ` and `--limit ` narrow that listing and apply only alongside it. ### MCP `jolli mcp` starts a Model Context Protocol server over stdio so AI agents can query your memories directly. `jolli enable` registers it into every detected host (the IntelliJ plugin too, when a compatible Node runtime is available), and each host picks it up on its next start with no manual setup. For the per-host config-file locations, see the [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). ```bash jolli mcp # start the server (normally launched by your agent) jolli mcp --reindex # rebuild the local search index and exit ``` The server exposes ten built-in tools: | Tool | Purpose | |---|---| | `search` | Full-text search over your historical decisions and implementations. | | `recall` | Load a branch's complete context. | | `get_decision_timeline` | Trace how one decision evolved across commits. | | `list_branches` | Catalog of branches that have memories. | | `get_pr_description` | Build a PR title and body from a branch's memories. | | `queue_status` | Report whether summary generation is still in progress. | | `bind_space` | Bind this repo to a Jolli Space. | | `list_spaces` | List the Jolli Spaces you can bind to. | | `push_memory` | Push a branch's memories to the bound Jolli Space. | | `status` | Report this repo's installation and configuration health. Same data as `jolli status` above. | All ten are present inside a repository. Outside one, only `list_spaces` is offered, since the rest have no repository to read. When you are signed in, the server may also register Jolli-hosted tools alongside them (`mcpPlatformToolsEnabled`, on by default); set it to `false` for a git-memory-only server. `jolli pr-description` and `jolli queue-status` mirror the matching tools, for skills and agents. ### Jolli Workflows `jolli workflow` inspects the Workflows of a git-backed Space you have cloned on this machine. It ships as a separate plugin, so install it alongside the CLI: ```bash 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. **The Spaces and Workflows plugins need `@jolli.ai/cli` at 0.99.17 or later.** From `space-cli` 0.99.11 and `workflow-cli` 0.1.1 they take the list of Jolli web addresses from the CLI itself rather than keeping their own copy, so a CLI that learns a new address teaches them the same one without a plugin release. On an older CLI the plugin is **skipped rather than loaded**, which means `jolli space` and `jolli workflow` stop appearing at all instead of failing with an error. If either command goes missing after an upgrade, that is the cause: ```bash npm i -g @jolli.ai/cli ``` The `workflow` command is listed in `jolli --help` even before the plugin is installed; running a subcommand without it prints an install hint. It needs a Jolli sign-in, and it only sees Spaces that are git-backed with the destination already cloned locally. | Command | What it does | |---|---| | `jolli workflow local-run` | List the Workflows that can be run locally right now. | | `jolli workflow runs ` | List a Workflow's run history: status, timestamps, deep links, and Article or pull-request URLs. | | `jolli workflow run-status ` | Watch a run until it reaches a final state, then print its report. | Two things to know: - **Every subcommand prints JSON**, not formatted text. These are built to be called by scripts and AI agent recipes rather than read in a terminal. - **None of them starts a run.** `local-run` reports what is eligible to run locally; starting a run is done from the web app with **Run now**, or by an AI agent connected to your Jolli workspace. - **An empty run history from `jolli workflow runs` does not always mean there are no runs.** If the call cannot reach the server, is not authorized, or names a Workflow that does not exist, it prints `{"type":"runs","runs":[]}` and exits successfully, exactly as it would for a Workflow that has genuinely never run. If you expected runs and got none, check your sign-in with `jolli auth status` and confirm the Workflow id before concluding the history is empty. For creating and scheduling Workflows, see [Workflows](https://docs.jolli.ai/jolli-spaces/workflows). Two skills are installed alongside these commands for running workflows from an AI agent: **`jolli-local-run`** runs a workflow on your own machine, so your agent executes the recipe and no Jolli LLM budget is used, and **`jolli-remote-run`** triggers a run on Jolli's backend and monitors it to completion. In Claude Code they appear under the `/jolli` menu. ### Jolli Spaces `jolli space` manages a Jolli Space from the command line: syncing its articles as markdown, mapping the source repositories it watches, running documentation impact analysis, and driving an agent over it. It ships as a separate plugin, so install it alongside the CLI: ```bash npm i -g @jolli.ai/cli @jolli.ai/space-cli ``` The `space` command is listed in `jolli --help` even before the plugin is installed; running a subcommand without it prints the same install hint. **Set up and inspect** | Command | What it does | |---|---| | `jolli space init` | Set up the current directory: sign in if needed, then pick the Space to work with. | | `jolli space status` | Report your sign-in and the selected Space. Add `--no-verify` for an offline check that skips the server. | | `jolli space switch` | Choose a different active Space for this directory. | | `jolli space ls` | List every Space you can reach, with its id, name, slug, and protocol. | | `jolli space clones` | List the git-backed Spaces cloned on this machine. Works offline. | **Sync articles** | Command | What it does | |---|---| | `jolli space sync` | Full two-way sync. This is what the bare command does. | | `jolli space sync full` | The same two-way sync, named explicitly. | | `jolli space sync down` | Pull server changes, or clone the Space's docs repository on a git-backed Space. Also available as `pull`. | | `jolli space sync up` | Push local changes as a change set, or open a pull request on a git-backed Space. Takes `-m` for the message and `--merge-prompt` for reviewer notes. Also available as `push`. | | `jolli space sync strip ` | Remove Jolli's frontmatter (`jrn`, `attention`) from markdown files. | | `jolli space sync pending` / `pending clear` | Inspect or clear sync operations queued for replay. | | `jolli space sync changeset checkout ` | Check out the files of one change set to review them locally. | | `jolli space sync changeset amend ` | Update an existing change set from your local edits. | **Sources and impact analysis** | Command | What it does | |---|---| | `jolli space source add --path ` | Map a source repository the Space watches. `--path` is required and must point at a git repository, absolute or relative. | | `jolli space source remove ` / `list` | Remove a mapping, or list what is mapped. | | `jolli space impact extract` | Pull the changed pieces out of a git diff, ready for analysis. | | `jolli space impact search` | Find which articles a diff affects. | | `jolli space impact agent` | Run an agent that updates the affected articles. | | `jolli space impact init` | Set up impact analysis that runs entirely on your machine, with no Jolli sign-in. | | `jolli space impact settings` | Set the model and API key that local analysis uses. | | `jolli space impact local` | Run local analysis over your new commits and edit the affected docs in place. | | `jolli space impact attention` | Build, refresh, or view the local map of which docs relate to which source files. | **Agent** | Command | What it does | |---|---| | `jolli space agent` | Start an interactive agent session against the Space. | | `jolli space agent list` | List your agent sessions. Also available as `ls`. | | `jolli space agent resume ` | Reopen an earlier session. | One more sits outside those groups: `jolli space verify-publish-branch [actual]` checks that a locally run Workflow published to the branch the server expected, printing the comparison as JSON and exiting non-zero when they disagree. It is meant for scripts and agent recipes rather than day-to-day use. > **The older flat commands still work, for now.** `jolli init`, `jolli source`, `jolli impact`, > `jolli sync`, `jolli agent`, and `jolli docs` are kept as hidden aliases of their `jolli space` > equivalents. Each prints a deprecation notice and they are removed in the next major release, so prefer > the `jolli space` form. There is no `jolli space docs`: the old `docs pull` and `docs publish` map to > `jolli space sync down` and `jolli space sync up`. ### Jolli Sites The site commands build a documentation site on your own machine: scaffold one, run it with hot reload, produce a static build with a search index, and manage themes. They ship as a separate plugin, so install it alongside the CLI: ```bash npm i -g @jolli.ai/cli @jolli.ai/site-cli ``` | Command | What it does | |---|---| | `jolli site new` | Scaffold a new documentation project. | | `jolli site convert` | Convert an existing documentation folder to the structure Jolli builds from. | | `jolli site build` | Build a static site, including its search index. | | `jolli site dev` | Start a dev server with hot reload. | | `jolli site start` | Build a production site and serve it. | | `jolli site reverse` | Work backwards from a Jolli build output to a `site.json`. | | `jolli site theme` | Manage themes: `list` shows what the theme registry offers, `install ` downloads one to `~/.jolli/themes/`, and `preview ` renders it with demo content. | `jolli site theme list` ends with the line `Built-in: default, forge, atlas`. Those three need no download. Note that `default` is available to a local build but is not offered when you pick a theme pack for a hosted Site in the web app, which starts from Forge and Atlas. > **The older flat commands still work, for now.** `jolli new`, `jolli convert`, `jolli build`, > `jolli dev`, `jolli start`, `jolli reverse`, and `jolli theme` are kept as hidden aliases of their > `jolli site` equivalents, so existing scripts keep running. Each one writes > `jolli is deprecated; use jolli site ` to standard error and then does its job, which > leaves anything reading standard output unaffected. Prefer the `jolli site` form. Before the plugin is installed, these commands appear in `jolli --help` under **Jolli Site** under their older flat names, since the `site` grouping arrives with the plugin itself. Running one then prints `npm install -g @jolli.ai/site-cli` and stops. This is for building a site locally. Publishing a Space as a hosted Site, custom domains, and access control are all done in the web app, and are covered in [Jolli Sites](https://docs.jolli.ai/jolli-sites). ### Telemetry Usage telemetry is content-free and on by default. For exactly which fields it sends, what it never sends, and every opt-out path, see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). | Command | What it does | |---|---| | `jolli telemetry status` | Show whether telemetry is on, plus the install ID and buffered event count. | | `jolli telemetry on` | Opt in. | | `jolli telemetry off` | Opt out. No events are collected or sent. | | `jolli telemetry inspect` | Print the exact buffered events that would be sent. | You can also opt out by setting `DO_NOT_TRACK=1`. See for the full event list. ## IDE commands The editor extensions expose the same actions in a sidebar. In VS Code (and forks such as Cursor and Windsurf) open the Command Palette (`Cmd/Ctrl+Shift+P`) and filter on **Jolli Memory**; in IntelliJ use Find Action (`Cmd/Ctrl+Shift+A`). The main commands and their CLI equivalents: | Command | What it does | CLI equivalent | |---|---|---| | Enable / Disable Jolli Memory | Install or remove the hooks in this repo | `jolli enable` / `jolli disable` | | Sign In to Jolli / Sign Out of Jolli | Manage your Jolli credential | `jolli auth login` / `jolli auth logout` | | Status | Open the Status overlay | `jolli status` | | Settings | Open the settings panel | `jolli configure` | | AI Commit | Generate a commit message from the staged diff | editor only | | Squash Selected | Squash selected commits and merge their Memories | editor only | | Search Memories / Clear Filter | Substring filter over the Memories list | `jolli search` (full-text) | | Sync Memory Bank Now | Run one Memory Bank cloud sync | `jolli sync-memory-bank` | | Build Knowledge Wiki | Compile commit memories into topic pages | `jolli compile` | | View Knowledge Graph | Open the knowledge-graph view | `jolli graph` | | Add Plan / Add Markdown File / Add Text Snippet | Attach a plan or note to the branch | editor only | | Share Memory / Share Branch | Publish memories to a team Jolli Space | `jolli push` | Create PR lives in the branch footer of the sidebar, not the palette. The IntelliJ settings page at Settings > Tools > Jolli Memory exposes the Anthropic API key, model, and Jolli API key; other keys are managed via the CLI or by editing `config.json` directly. ## Agent plugins Claude Code, Cursor, and Codex each have their own install path that needs no CLI setup. Installing the plugin gives you that agent's `jolli` skills, a bare `jolli` menu, and Memory's MCP tools already connected. See [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) for the full surface, how the three differ, and what to check when nothing appears to happen. ## Agent support matrix Jolli Memory captures fourteen sources across eleven agents. Each has a config toggle in the keys table above (`claudeEnabled`, `codexEnabled`, `geminiEnabled`, `openCodeEnabled`, `cursorEnabled`, `copilotEnabled`, `clineEnabled`, `devinEnabled`, `antigravityEnabled`, `kimiEnabled`, and `hermesEnabled` - three of those each cover two sources: `cursorEnabled` (the Composer IDE + the `cursor-agent` CLI), `copilotEnabled` (both GitHub Copilot sources), and `clineEnabled` (the Cline VS Code extension + CLI)). Claude Code, Gemini CLI, and Hermes Agent on macOS and Linux capture through an agent hook, so restart them after `jolli enable`; the other eleven are discovered at commit time and need no hook or restart. For each source's capture mechanism, session location, and Node 22.13+ requirement, see the [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture). ## Troubleshooting If something is not working, run this first: ```bash jolli doctor # checklist of hook, credential, and queue state jolli doctor --fix # release stale locks and reinstall missing hooks ``` For specific problems, such as summaries not generating, sign-in failures, or sync and Share in Jolli errors, see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). If you still need help, email support@jolli.ai with your `jolli doctor` output. ## Related - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. - [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) - fixes for the common problems, and what data goes where. - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - how each agent's sessions are captured. - [Jolli Memory in CI and Automation](https://docs.jolli.ai/jolli-memory/jolli-memory-in-ci-and-automation) - headless auth, waiting for summaries, env vars, and backfill. --- # Supported AI Agents and Capture Source: https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture ## Overview Jolli Memory captures the reasoning behind your work automatically. On every commit, a background worker finds the AI coding session that produced the work, reads its transcript and your git diff, and attaches a structured Memory to the commit. This page lists every agent Memory can capture, how each one is captured, which surfaces can do what, and how to turn any source on or off. Private and local-first: your summaries and transcripts are stored with your repo. Generating a summary sends your transcript and diff to the LLM for that request (never stored off-machine); nothing is published to anyone else until you Share in Jolli. ## Prerequisites - Memory enabled in a git repository (`jolli enable`). - **Node 22.13 or later** for the `jolli` CLI, and for the sources marked **Yes** in the "Node 22.13+?" column below, which read a local SQLite database. - Hook-based agents (Claude Code, Gemini CLI, and Hermes Agent on macOS and Linux) must be restarted after enabling. When you set Jolli up with the CLI, one restart is also what brings the MCP tools in. The agent plugins differ, and the [plugin page](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) has the per-host detail. ## What "capture" means Capture is the step where Memory turns a coding session into a stored Memory: 1. You code with an AI agent in a git repo where Memory is enabled. 2. You commit. 3. In the background, Memory finds the session that produced the work, reads its transcript and the diff, and generates the Memory. Each Memory names the agent that produced it, so you can use more than one agent in the same repo and still tell them apart. Memory finds your session in one of two ways, depending on the agent. Some agents run a hook that records the session as it happens. Others have no usable hook, so Memory discovers the session by reading files or a local database at commit time. Both models are explained below. ## Supported agents at a glance Memory captures fourteen sources across eleven agents. Some agents have more than one capture path that shares a single toggle - GitHub Copilot, Cursor, and Cline each do. Every source is enabled automatically when its agent is detected, unless you turn it off. | Agent | Capture mechanism | Where sessions live | Node 22.13+? | Toggle | Auto briefing | | --- | --- | --- | --- | --- | --- | | Claude Code | Hook (Stop hook records the session) | `~/.claude/` | No | `claudeEnabled` | Yes | | Gemini CLI | Hook (after-agent hook records the session) | `~/.gemini/tmp//chats/` | No | `geminiEnabled` | No | | Hermes Agent | Hook on macOS and Linux (`on_session_end` records the session); discovery elsewhere (local SQLite database) | `~/.hermes/state.db`, or `%LOCALAPPDATA%\hermes\state.db` on Windows. `HERMES_HOME` overrides both | Yes | `hermesEnabled` | No | | Codex CLI | Discovery (filesystem scan) | `~/.codex/sessions/` and `~/.codex/archived_sessions/` | No | `codexEnabled` | With the plugin | | OpenCode | Discovery (local SQLite database) | `~/.local/share/opencode/opencode.db` | Yes | `openCodeEnabled` | No | | Cursor (Composer IDE) | Discovery (local SQLite database) | Cursor's `globalStorage/state.vscdb` | Yes | `cursorEnabled` | With the plugin | | Cursor CLI (`cursor-agent`) | Discovery (filesystem scan) | `~/.cursor/chats/` and `~/.cursor/projects/` | No | `cursorEnabled` | With the plugin | | GitHub Copilot CLI | Discovery (local SQLite database) | `~/.copilot/session-store.db` | Yes | `copilotEnabled` | No | | GitHub Copilot Chat | Discovery (filesystem scan) | VS Code workspace storage and `~/.copilot/session-state/` | No | `copilotEnabled` | No | | Cline (VS Code) | Discovery (filesystem scan) | `/User/globalStorage/saoudrizwan.claude-dev/state/taskHistory.json` | No | `clineEnabled` | No | | Cline CLI | Discovery (filesystem scan) | `~/.cline/data/sessions/` | No | `clineEnabled` | No | | Devin | Discovery (local SQLite database) | `~/.local/share/devin/cli/sessions.db` (`%APPDATA%\devin\cli\sessions.db` on Windows) | Yes | `devinEnabled` | No | | Antigravity | Discovery (local SQLite database) | `~/.gemini//conversations/` | Yes | `antigravityEnabled` | No | | Kimi Code CLI | Discovery (filesystem scan) | `~/.kimi-code/sessions/` (or `$KIMI_CODE_HOME/sessions/`) | No | `kimiEnabled` | No | Notes: - The three shared toggles are spelled out under Turning a source on or off, below. - "Auto briefing" means the automatic session-start briefing, covered below. ## What works where The table above is about which *agents* Memory captures from. This one is about the *surfaces* you drive Memory through, because they do not all offer the same things. | Where you run it | Recall and search | Push to a Space | Sign in from here | | --- | --- | --- | --- | | CLI | Yes | Yes | Yes | | VS Code extension | Yes | Yes | Yes | | JetBrains plugin | Yes, needs Node on `PATH` | Yes | In the tool window | | Claude Code plugin | Yes | Yes | `/jolli:login` | | Cursor plugin | Yes | Yes | `/jolli-login` | | Codex plugin | Yes | Yes | `$jolli:login` | | Jolli in your browser | Search only | n/a - it is the destination | Yes | For where you can open the local dashboard from each of these, see [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). **JetBrains is the narrowest surface.** Its skills and MCP tools need Node on your `PATH`; without Node the tool window shows "MCP & Skills: Node.js not found". Memory generation still works, because it runs on native Java hooks. It also does not read **Hermes Agent** sessions yet: every other source in the table above is captured, but Hermes work done alongside a JetBrains IDE needs the CLI installed to be picked up. ## The two capture models ### Hook-based: Claude Code, Gemini CLI, and Hermes Agent > **Set Claude Code up with the plugin?** The mechanism below is the same, but the plugin installs the hook itself instead of you running `jolli enable`. See [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent) for that path, and for the Cursor and Codex plugins. These agents record each session through an agent hook, installed either by `jolli enable` or by the Claude Code plugin. Because the hook runs inside the agent, it only loads on a start that happens after the hook is in place: if one was already running when Memory was set up, restart it or the session is not recorded. Claude Code's hook is the Stop hook, which records the session when a turn ends. Gemini CLI's is an after-agent hook, and Gemini gets no session-start briefing - use Recall instead. Hermes Agent's is an `on_session_end` hook, written into `~/.hermes/config.yaml`. Two things are specific to it: - **The hook is installed on macOS and Linux only.** On Windows, Memory registers its MCP server but no hook, so Hermes sessions there are found by the discovery model instead, at commit time. - **Every Hermes profile is set up, not just the default one.** `hermes profile` gives you separate Hermes instances under `~/.hermes/profiles/`, each with its own config and its own session database, so Memory writes to all of them. Setting up only the default would look like it worked while the profile you actually use recorded nothing. Hermes asks before it will run a hook a tool has added. Memory adds its own entry to Hermes' allowlist when it sets the hook up, so you are not prompted for this one. ### Discovery-based: every other source The other eleven sources have no hook that Memory can use. Instead, Memory discovers the session at commit time by scanning the filesystem or reading a local database. There is nothing to restart for capture. As long as the agent wrote its session to the expected location and you committed within the freshness window, the session is found. Every host does still need one restart before Memory's MCP tools appear, because an agent reads its MCP configuration at startup. See [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). A single full restart covers that, a capture hook loading, and - with an agent plugin - setup running at all; you never need more than one. ## Per-agent notes The table above gives each source's session location, its toggle, and whether it needs Node 22.13+. Three details it cannot hold: - **OpenCode**: if you use a non-standard data directory, set `XDG_DATA_HOME` so Memory can find the database. - **Antigravity**'s variant folder is one of `antigravity`, `antigravity-ide`, or `antigravity-cli`. - **Kimi Code CLI** also contributes **references** and **captured skill usage**, both covered further down this page. ## Node 22.13+ prerequisite **Why 22.13 and not 22.5.** Node's built-in SQLite first appears in 22.5, but until 22.13 it only loads behind a startup flag, and the two places that matter here cannot pass one: the VS Code extension host and the git hooks. So 22.13 is the real floor for the sources marked **Yes** in the "Node 22.13+?" column above. The install script checks the major version only, so it accepts any Node 22 and reports success; `npm`'s `engines` field is what refuses afterwards. - On the CLI, this is your installed Node version. - In VS Code (or a fork such as Cursor or Windsurf), you need a build recent enough to bundle Node 22.13+, and the extension itself now requires **VS Code 1.101 or later**. On 1.100 and earlier the Marketplace stops offering the update, so the extension quietly stays at whatever version you already have rather than telling you it is out of date. If the runtime is older, those sources are reported as not detected rather than as an error: they simply will not appear in `jolli status`. Sources that read plain files have no Node requirement. **"Not detected" here means capture only, not MCP.** Registering Jolli's MCP server only writes a config file, so it checks whether the agent is installed rather than what your Node version is. On an older runtime one of these six can therefore be missing from `jolli status` while its Jolli tools work normally in the chat: the agent is wired up for questions about your memories, and only automatic capture is waiting on a newer Node. ## Auto-linked references When a session mentions an issue, page, thread, or meeting in a supported tool, Memory can attach it to the Memory as a reference. There are two kinds of reference: **With-context references** - the title, a link, and a few key fields are captured, and the reference is included as context when Memory generates the summary. Ten trackers produce with-context references: - Linear - Jira - GitHub - Notion - Confluence - Asana - monday.com - Slack - Zoom (meetings) - Zoom (docs) **Tracking-only references** - a lightweight bookmark: the link and a short label are recorded so you can see what the session consulted, but the fetched content is not saved and the reference is not fed into the summary. A near-empty body on one of these is expected, not a bug. Five sources are tracking-only today: - Context7 (library-documentation lookups) - records the library, a Context7 link, and your query only. Each Context7 reference carries a short note on its page saying so. - Jolli Memory itself - when a session consults your own memory through the `recall`, `search`, or `get_decision_timeline` tools, that lookup is recorded as a reference with the queries you asked. It is the one reference with no link to follow, because there is no external page to open. Keeping it out of the summary is deliberate: recalling memory must never feed back into the memory being written. - Vercel (deployments), Figma (design files), and Sentry (issues) - the link and a short label are recorded, and the fetched detail is not saved. These three are matched on the Claude Code path only, so Claude Code and Kimi Code CLI reach them and Codex does not. Coverage by agent: references are extracted from **Claude Code**, **Codex CLI**, **Kimi Code CLI**, and **Hermes Agent** sessions - other agents still produce full Memories but no auto-linked references yet. Hermes is read a different way from the other three, out of its SQLite store rather than a transcript file, but what you get out of it is the same. Claude Code covers all ten with-context trackers, plus all five tracking-only sources. Codex covers nine of the ten with-context trackers - everything except Zoom docs - plus Context7 and Jolli Memory. Kimi Code names its tool calls the same way Claude Code does, so it is matched on the same path and reaches the same trackers, for anything you use through that tracker's MCP server. Kimi transcripts carry no pasted Slack links, so a Slack reference there takes its URL from the `slack.workspaceUrl` setting. ## Captured skill usage Alongside the conversation itself, Memory records which **skills** a session entered, so a commit shows the skills that produced it and roughly what they cost. Both ways of entering a skill are counted: the agent choosing it, and you typing it as a slash command. Four sources report skill usage: | Source | How it is measured | | --- | --- | | Claude Code | Read directly from the session's own record of entering the skill. | | Codex CLI | Inferred, because Codex has no skill concept of its own - only a shell command that reads a skill file. Inferred rows are marked in the table. | | OpenCode | Read from OpenCode's local database. | | Kimi Code CLI | Read directly. Kimi has a real skill tool, so every entry is observed rather than inferred. | The other sources report nothing here, and that is not a gap waiting to be filled: Gemini CLI, Antigravity, Cline, and Devin have no on-disk notion of a skill, so there is nothing for Memory to find. Cursor ships skills but leaves no record of running one, so it reports nothing either. You see the result in two places, and they render the same table: - In your Memory Bank folder, as a `skills--.md` file per commit. - In the VS Code sidebar, for the work you have not committed yet. The table lists each skill, which agent entered it, how many times, and its token totals split into input, output, and cached. Two things are deliberate: an inferred row carries a footnote marker, and a skill whose cost could not be attributed shows a dash rather than a zero, because zero would read as a measurement. An estimated figure is prefixed with `~`. There is no separate setting for this. Skill usage follows the same per-agent toggle as everything else that source captures, so turning the source off turns this off with it. ## Which agent did the work From CLI 0.99.14, Memory records which AI tool each conversation, commit and skill came from, so you can tell your Claude Code work from your Codex work after the fact. Both dashboards use it: the local one breaks tool and skill usage down by agent, and references and memories carry their source's own badge. The recorded value is one name from a fixed list, never free text, and it is **left out rather than guessed** when the tool cannot be determined. A blank means "not measured", not "the CLI". Two details are worth knowing if a figure looks thinner than you expect: - **Kimi Code and Devin are identified at commit time only.** Neither leaves anything in the environment that Jolli can read while a session is running, so work in them is attributed when the commit lands rather than as it happens. - **A shared session server does not guess.** When several tools share one Memory server for a checkout, attribution comes from each tool's own connection rather than from the environment the server started in, because that environment belongs to whichever tool happened to connect first. Older memories carry no agent at all, and nothing fills it in retroactively. ## Session-start briefing vs Recall An **automatic** session-start briefing (the "Auto briefing" column above) is a short `[Jolli Memory — ]` block prepended to a new session in a repo with Memories, on feature branches only. Three agents get one, and what it takes differs: - **Claude Code** gets it from the CLI alone, with nothing extra to install. - **Cursor** and **Codex** get it once you install the Jolli plugin for that agent. Without the plugin, neither does. Every other agent pulls context on demand with `jolli recall` or the recall skill. For the briefing's size, the branches it skips, when to run an explicit Recall instead, and the per-agent setup, see [Recall vs Search](https://docs.jolli.ai/jolli-memory/recall-vs-search) and [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). ## Turning a source on or off Every source is enabled automatically when its agent is detected. To turn one off, set its toggle to `false`. From the CLI: ```bash jolli configure --set cursorEnabled=false # stop capturing Cursor jolli configure --set codexEnabled=true # capture Codex again jolli configure --set kimiEnabled=false # stop capturing Kimi Code jolli configure --remove cursorEnabled # back to auto-detect jolli configure --list-keys # list every config key ``` In VS Code (or a fork such as Cursor or Windsurf) or IntelliJ, use the Settings panel. All surfaces read the same config file at `~/.jolli/jollimemory/config.json`, so a change in one place applies everywhere. Toggle defaults: - `claudeEnabled` defaults to on. The rest default to auto-detect, which means on whenever the agent is detected. - Three toggles each cover two sources: `copilotEnabled` (GitHub Copilot CLI + Chat), `cursorEnabled` (the Composer IDE + the `cursor-agent` CLI), and `clineEnabled` (the Cline VS Code extension + the Cline CLI). ## My tool isn't captured Work through these in order: 1. Run `jolli status`. It lists each detected agent, whether it is enabled, and how many recent sessions it found. If your agent is missing entirely, it was not detected. 2. Check your Node version for the SQLite-backed sources, marked **Yes** in the "Node 22.13+?" column above. These need Node 22.13+. On an older runtime they show as not detected. 3. Restart hook-based agents. Claude Code and Gemini CLI must be started after `jolli enable`. If you started one first, restart it. 4. Mind the freshness window. Memory only considers sessions updated within the last 48 hours. An older session is not picked up. 5. Confirm the detection path. The agent must have written its session to the expected location listed in the table above. A non-standard install or data directory can hide it. For OpenCode, set `XDG_DATA_HOME`. If a commit was made with no supported agent running, there is no transcript to read, and Memory falls back to a diff-only summary. ## Related - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. - [Recall vs Search](https://docs.jolli.ai/jolli-memory/recall-vs-search) - how the Claude Code briefing and manual Recall reach your next session. - [Reference](https://docs.jolli.ai/jolli-memory/reference) - the per-agent config toggles and other keys. --- # The Local Dashboard Source: https://docs.jolli.ai/jolli-memory/the-local-dashboard ## Overview `jolli dashboard` opens a dashboard for your memories in your browser. The server runs on your own machine, started by the command, reading the memories Jolli has already captured. No Jolli account is needed to run it. There is a second, different dashboard in the Jolli web app, which reports what has been synced to your organization. This page is about the local one. ```bash jolli dashboard ``` Run it from inside a repository and it registers that repository, opens the page, and keeps serving until you stop it. Memory does not have to be enabled there yet: the pages all render, and before you have enabled anything they tell you what to do rather than sitting empty. ## Prerequisites - The `jolli` CLI installed, and **Node 22.13 or later** - the same floor as the CLI itself, because the dashboard's database uses Node's built-in SQLite. On an older runtime the command reports the version it needs instead of starting. - Nothing else. No Jolli account, and no repository enabled yet. ## Where you can open it The dashboard is local, and it is the CLI's. Every surface that offers it is running the same `jolli dashboard` underneath: | Where you open it | How to open it | | --- | --- | | CLI | `jolli dashboard` | | VS Code extension | **Jolli Memory: Open Dashboard** in the Command Palette, or the **Dashboard** button in the branch footer. Both start it in a terminal, so you can watch it work and stop it with Ctrl+C. Needs the CLI on your `PATH`. | | Claude Code, Cursor, Codex plugins | Ask for the dashboard, or run the skill directly: **`/jolli:dashboard`** in Claude Code, **`/jolli-dashboard`** in Cursor, **`$jolli:dashboard`** in Codex. Each plugin bundles its own copy of the CLI, so there is nothing extra to install. Add "url only" if you would rather have the address than a browser window. | | JetBrains plugin | Not available from the plugin. Run `jolli dashboard` in a terminal instead. | | Jolli in your browser | Not this dashboard. Jolli has a **Dashboard** page of its own, which reports synced activity instead of reading your machine - see below. | **The two dashboards are different things.** This one runs on your machine, reads what is stored there, and needs no account. The **Dashboard** pages inside Jolli report what your machines have synced to your organization, and can show a team view alongside your own. Most of what is here now has a counterpart there: **Knowledge** and **Graph** are the two that exist only on your own machine. ## What you see Six pages sit in the sidebar to begin with: **My Dashboard**, **Daily Standup**, **Skills**, **MCPs**, **Coaching**, and **Memories**. **Knowledge** and **Graph** are switched off until you ask for them. **Settings** is pinned to the bottom of the sidebar and opens over whichever page you are on rather than replacing it. | Page | Address | What it shows | | --- | --- | --- | | **My Dashboard** | `/dashboard` | Your own activity: how much you have captured, per-repository totals, and trends over a date range you choose. | | **Daily Standup** | `/dashboard/standup` | Your recent committed work, a week at a time, for the question "what did I do since yesterday". | | **Skills** | `/skills` | Which skills have run and which agent ran each one, at more detail than the My Dashboard card. | | **MCPs** | `/mcps` | Which MCP servers your agents called, day by day, with the calls and tools for each one. The counterpart to Skills for the other half of what an agent reaches for. | | **Coaching** | `/dashboard/journeys` | A read of your journeys for the window you pick: plan-first share, top skill, cost, and recall, with your smoothest and hardest journeys called out. Marked **beta**. | | **Memories** | `/memories` | Browse the captured memories themselves, per commit. | | **Knowledge** | `/knowledge` | Browse the wiki Jolli builds from your memories. Switched on under **Settings → Advanced**. | | **Graph** | `/graph` | The knowledge graph for a repository, shown in the page. Switched on under **Settings → Advanced**. | Every page is reachable as soon as the dashboard starts. Before you have enabled anything, **My Dashboard** tells you what to do rather than sitting empty: it shows **No repositories yet** and asks you to run `jolli enable` inside the repository you want to start with. **Knowledge** and **Graph** are hidden from the sidebar until you turn them on under **Settings → Advanced**. Hiding a row does not close the page: a link or a bookmark to either address still opens it, and the Knowledge page's own link to the graph keeps working. Both read your Memory Bank folder rather than the dashboard's own registry, so the repositories they cover can differ from the ones listed elsewhere, and each has its own empty state when there is nothing to show yet. **Settings** holds six sections: **AI Agents**, **AI Summary**, **Sync to Jolli**, **Memory Bank**, **Others**, and **Advanced**. It has no address of its own, so it opens from the sidebar rather than from a URL. ## Starting and stopping it The dashboard runs in your terminal. `jolli dashboard` serves it until you press **Ctrl+C**, and the command does not return before then. ```bash jolli dashboard --no-open # serve it and print the URL instead of opening a browser jolli dashboard --port 3000 # serve on a specific port jolli dashboard --cwd # register a different repository than the current directory ``` Without `--port` it uses **1818**, and falls back to **18118** if that one is taken. Running `jolli dashboard` again replaces the one already running, so you always get a fresh dashboard at the address you expect. If an older version left a server running in the background, the new run takes it over. Anything else using port 1818 is left alone. Earlier versions kept the server running in the background and stopped it with `jolli dashboard --stop`. That flag no longer exists, because there is no longer a background server to stop. ## What happens on the first launch The dashboard reads from its own local database rather than re-reading git on every page load, so the first launch has to fill that database from the memories you already have. That import runs in the background while the page is open: the page renders whatever is stored so far and fills in as the sweep lands, rather than making you wait. It also looks through your agents' own session history from the last seven days, not only what Jolli had already recorded, and prints one line saying what it picked up. This import is not the same thing as `jolli backfill`. It only reads summaries that already exist, so it makes no AI calls and costs nothing. Creating memories for commits made before you enabled Jolli is still an explicit `jolli backfill`, run from the CLI. ## More than one repository The dashboard is not scoped to the repository you launched it from. It keeps a registry of repositories, and each `jolli dashboard` run adds the one you ran it from, so over time it becomes a view across everything you work on. Per-repository totals on **My Dashboard** reflect that registry. The repository picker in the top bar chooses which of them you are looking at. It filters the view and nothing more: it does not enable, pause, or resume anything. Turning Memory on or off for a repository is `jolli enable` and `jolli disable`, run inside that repository. Disabling removes that repository's hooks, so no new memories are captured there until you enable it again. Existing memories are never touched, and the repository keeps its row, so enabling it again needs no second import. ## Who can reach it Three things are true about access, and they are worth knowing if you are wondering whether an open port is a problem: - The server listens on **loopback only** and serves only `localhost` and `127.0.0.1` addresses. It is not reachable from another machine on your network. - It sends no cross-origin headers, and rejects any request that arrives from a web page, so a site you have open in another tab cannot read what it serves. - Actions that change something, such as enabling a repository or applying a setting, are additionally protected by a token that exists only in the running server's memory and is never put in a URL. Reading pages needs no credential, which is why `http://localhost:1818/dashboard` simply works if you would rather type it than have a browser opened for you. **The database behind these pages is not only read locally, though.** When you are signed in, Jolli uploads statistics from it to your organization: session counts, models, tokens, estimated cost, tool and skill names, and session titles, for every repository Jolli is enabled in. That is what fills the web dashboard. It is a switch you control - **Settings → Sync to Jolli** here, or `jolli configure --set syncSessions=false` - and [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) covers exactly what it does and does not send. ## Related - [Reference](https://docs.jolli.ai/jolli-memory/reference) - the full flag list for `jolli dashboard` and every other command. - [Memory Bank and Sync](https://docs.jolli.ai/jolli-memory/memory-bank-and-sync) - where memories are stored on disk, and the one-way move to local database storage. - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. --- # The Web Dashboard Source: https://docs.jolli.ai/jolli-memory/the-web-dashboard ## Overview **My Dashboard** is a group of pages in the sidebar when you open Jolli in your browser. They report what your organization's machines have synced: the memories and decisions your repositories pushed, and the sessions your AI tools ran. Everything is filtered by a date range and a set of repositories you choose. There are two groups, **My Dashboard** and **Team Dashboard**, holding the same five pages each. The group says whose work you are reading: your own, or everyone's. This is not the same thing as `jolli dashboard`, which runs on your own machine and reads it directly. That one is [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). Both call their personal view **My Dashboard**, so if you need to be sure which you are looking at, the line under the heading says: **individual · synced** here, **individual · local** there. ## Prerequisites - Nothing, for the **My Dashboard** group. Everyone can open it. - **View Team Memory Activity** permission, for the **Team Dashboard** group. **Owners and administrators have it; members do not.** If you need it and you are a member, your administrator can move you to a custom role that includes it. See [Settings](https://docs.jolli.ai/settings). - For the session half of these pages to have anything in it, session statistics must be syncing from at least one machine. That needs the CLI at **0.99.14 or later** and someone signed in on it. See **Where the numbers come from** below. ## The two groups | Group | Address | Who can open it | | --- | --- | --- | | **My Dashboard** | `/dashboard` | anyone | | **Team Dashboard** | `/dashboard/team` | needs **View Team Memory Activity** | **My Dashboard** reports your own work. **Team Dashboard** reports everyone in the organization: their commits, branches, sessions and spend. The **Team Dashboard** group is simply absent from the sidebar if you do not have the permission, and the address refuses too, so a shared link cannot get around it. If you had the old **Analytics** page bookmarked, that address now lands here. ## The five pages Each group holds the same five pages. Every one takes the same date range and repository picker, and reads whichever scope its group names. | Page | Address | What it answers | | --- | --- | --- | | **Dashboard** | `/dashboard` | The overview: all the cards described below, on one page. | | **Standup** | `/dashboard/standup` | A week of committed work laid out as day columns, for "what did I do since yesterday". A weekly pager moves back and forward. Only work that reached a commit and synced appears, so uncommitted work and local changes are not shown. | | **Coaching** | `/dashboard/coaching` | Your journeys read against your own earlier line: how many in the window, plan-first share, cost and recall, with individual journeys openable as a trace. Marked **Beta**. | | **Skills** | `/dashboard/skills` | Every skill day by day, with runs and tokens, and per-skill detail. More grain than the Skills card. | | **MCPs** | `/dashboard/mcp` | Every MCP server day by day, with calls and tools, and per-server detail. More grain than the MCPs card. | Under **Team Dashboard** the same five sit at `/dashboard/team`, `/dashboard/team/standup`, and so on. The team Coaching page reads against the team's earlier line rather than your own, and reports across members. ## Choosing what you are looking at **A date range.** **7d**, **30d** and **90d** are one click each. **Custom** opens a calendar with quick ranges beside it: **Last 14 days**, **This month**, **Last month**, and **Year to date**. The longest range you can ask for is **366 days**. **A set of repositories.** The picker defaults to **All repositories**. Clearing it entirely is possible in one click, so if you get **Select at least one repository**, that is what happened. ## What each card reports These are the cards on the **Dashboard** page itself. **Skills** and **MCPs** appear here as cards and again as their own pages, where the same data is broken out per skill or per server. | Card | What it counts | | --- | --- | | **Memory Activity** | Memories captured over the range, split however you choose: by type, model, repo, branch or time. | | **Decisions** | Decisions your sessions recorded, accumulating across the range, each with the commit behind it. | | **Skills** | Skill invocations, read from the tool calls in synced sessions. A skill invoked inside a subagent counts once, against the session that spawned it. | | **MCPs** | MCP tool calls: which tool, and how often. Never the arguments or the results. Only servers that actually made a call in the range appear. | | **Tokens** | Daily token use, stacked as **Input**, **Output** and **Cache**. | | **Spend** | Daily estimated cost. | | **What my agents did** | The session feed itself. On the Team view it reads **What the team's agents did**. | Two things about the numbers are worth knowing before you rely on them: - **Spend is an estimate, never an invoice.** It is calculated from the usage in synced sessions and the price table in effect for each model. - **Cache reads bill at a fraction of input**, so a rising cached share lowers cost while token counts climb. That is why **Tokens** and **Spend** can move in opposite directions, and why they are two cards rather than one. Each card carries a short note on its own title explaining what it counts. Ranked lists load a page at a time: **Show more** brings one more page, not the whole list. ## Where the numbers come from The page has two halves, and they arrive by different routes. This is why it can look half-empty. - **Memories and decisions** arrive when your repositories push memories, which is the same path as Share in Jolli. If you are pushing memories, this half has data. - **Sessions, skills, MCP calls, tokens and spend** arrive over the session-statistics channel, which uploads from a signed-in machine running **CLI 0.99.14 or later**. It is on by default once you are signed in, and it covers every repository Jolli is enabled in on that machine. So if the memory cards have data and the session cards do not, nobody's machine is uploading session statistics yet. The empty state says so in as many words: memories appear after your next commit, and session statistics additionally need the session sync. **Every surface can now feed these pages.** The **JetBrains plugin** bundles its own copy of the CLI and is at 0.99.17, and the **Claude Code, Cursor and Codex plugins** bundle theirs at 0.99.16, so a signed-in machine reports from any of them like any other. The plugins run one release behind the CLI between their own updates, because a new plugin build is what carries a new engine. If your session cards are empty on a machine that only has a plugin, check you have taken the plugin update. The setting that controls the session half is `syncSessions`, on by default once you are signed in. If the session cards stay empty on a machine you expect to be reporting, push whatever is waiting rather than waiting for the next upload, which is throttled: ```bash jolli doctor --sync-sessions ``` That reports what it sent, or why it sent nothing. For exactly what the session channel sends, and how to switch it off, see [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq). ## What is not here The knowledge **Wiki** and the **Graph** have no equivalent here. They exist only in the local dashboard, on your own machine. **Coaching** and the **Standup** used to be local-only as well and are now on both. See [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard). ## Related - [The Local Dashboard](https://docs.jolli.ai/jolli-memory/the-local-dashboard) - the dashboard that runs on your own machine, and what only it can show. - [Troubleshooting and FAQ](https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq) - what session statistics carry, and how to turn them off. - [Settings](https://docs.jolli.ai/settings) - roles, the permission matrix, and API keys. - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - how each session gets attributed to an agent, which is what the per-agent breakdowns here are built on. --- # Troubleshooting and FAQ Source: https://docs.jolli.ai/jolli-memory/troubleshooting-and-faq ## Overview This is the place to look when Jolli Memory is not behaving, and the place to check the common questions before you adopt it. Part 1 walks through problems in the order they usually happen. Part 2 answers the questions people ask most. Whatever the symptom, run `jolli doctor` first. ## Part 1: Troubleshooting ### Start here: jolli doctor `jolli doctor` is the first thing to run for any problem. It prints a health checklist and tells you what, if anything, is broken. ```bash jolli doctor ``` Each line is one check: | Check | What it means | Healthy state | | --- | --- | --- | | Git hooks | The post-commit, post-rewrite, prepare-commit-msg, and post-merge hooks (a separate pre-push hook handles sync-on-push) | installed | | Claude hook | The Claude Code Stop and SessionStart hooks (optional) | installed | | Gemini hook | The Gemini CLI AfterAgent hook (optional) | installed | | System of record | Which store holds this repo's Memories, and whether it is reachable. This is the row that answers "can Memories be stored at all" | `orphan branch (jollimemory/summaries/v3)`, or `SQLite (...)` once the repo is cut over | | Orphan branch | The `jollimemory/summaries/v3` branch. Informational only - it never fails | `exists`, or `not yet created (will be created on first commit)`. After a cut-over to SQLite it reads `absent (expected...)` or `present but frozen`, and both are healthy | | Worker lock | The background worker's lock file, flagged stuck when older than 5 minutes | not stuck | | Sessions | Count of tracked agent sessions (informational only) | any number | | Git queue | Pending summary operations, flagged high above 10 entries | empty or low | | Config | Whether a usable credential is available | credentials found | | Local agent CLI | Only shown when you generate summaries with a local agent CLI. Finds the agent's binary and reports its version | the binary and version it found | | dist-paths | The per-source paths the hooks resolve to at runtime | at least one registered | | Global daemon | The shared background daemon, reported as context for the backup row below | running | | Database backup | Whether snapshots of the local database are being taken. Stale snapshots or an invalid backup folder fail; an unreachable drive warns, and escalates after seven days | recent snapshot | | Memory tree | Whether the stored Memory tree still has a reachable root, which an amend, rebase or squash can strand | reachable | | Repo registry | The list of repositories Jolli knows about on this machine, flagged when an entry's folder is gone | every entry resolves | | Dashboard events | Dashboard events waiting to be processed, flagged when some are stuck | none parked | | plugin ... | Version compatibility of any installed plugin | compatible | The **Local agent CLI** row is worth understanding, because it catches a problem the **Config** row cannot. When your provider is a local agent, the "credential" is a program on your machine rather than a stored key, so a healthy **Config** row only tells you the provider is selected. This row goes further and actually looks for the binary. If it cannot find one, the message names the sign-in step for that agent, and every commit will otherwise fail quietly. If you set `localAgentPath` by hand, the message also tells you that discovery was skipped because of it, and how to clear it. If a check fails, `doctor` exits with an error so you know to act. To repair automatically: ```bash jolli doctor --fix ``` `--fix` repairs five things: - Releases a stale worker lock. - Reinstalls missing git hooks. - Removes stale dist-path entries. - Takes a database snapshot when one is overdue. - Un-parks stuck dashboard events. One further repair is deliberately held behind a second flag: `--fix --forget-dead` also drops registry entries whose folder is gone. That **deletes those repositories' memories**, and no backup here restores them, so it is never part of a plain `--fix`. `--fix` does not clear the queue. To remove expired queue data, run `jolli clean`. To work through a backlog of pending summaries, make one more commit (see [Stuck or backlogged queue](#stuck-or-backlogged-queue)). If `doctor` did not pin the problem, the sections below cover what it does not. ### The install finished, but there is no `jolli` command The symptom is that the install script or `npm install -g @jolli.ai/cli` runs to the end without an obvious error, and then `jolli --version` reports that the command does not exist. Almost always this is the Node version. Jolli Memory requires **Node 22.13 or later**, and the package refuses to install on anything older. The install script's own check is coarser than that - it looks at the major version only, so a machine on Node 22.5 through 22.12 passes it, hands off to `npm`, and npm is the one that refuses. The script does not print npm's output on a run it considers successful, so the refusal is not shown to you. Check what you actually have: ```bash node --version ``` If it is below 22.13, upgrade Node and install again: ```bash nvm install 22.13 npm install -g @jolli.ai/cli jolli --version ``` To see the refusal for yourself rather than inferring it, skip the script and run `npm install -g @jolli.ai/cli` directly - npm prints an `EBADENGINE` warning naming the version it wanted and the version it found. You may also see a lower figure quoted while you are setting up. The install script asks for Node 22 or later, because it checks the major version only. 22.13 is the one that is enforced, so a machine on Node 22.5 through 22.12 clears the script's check and is then refused by `npm`. ### No Memory after a commit The most common problem. Work through these in order. **1. Restart your agent.** This is the single most frequent cause. Two agents capture sessions through hooks, and those hooks only take effect for sessions started after you enabled Jolli. If you enabled Jolli while your agent was already open, restart it (in VS Code or a fork like Cursor or Windsurf, reload the window; in IntelliJ, restart the IDE). Use the table below to see whether your agent needs a restart. | Agent | How sessions are captured | Restart after enable? | | --- | --- | --- | | Claude Code | Stop hook records each response, SessionStart hook injects a briefing | Yes | | Gemini CLI | AfterAgent hook fires after each completion | Yes | | Codex CLI | Discovered automatically by scanning the filesystem | No | | OpenCode | Discovered automatically from a local SQLite database (requires Node 22.13+) | No | | Cursor IDE (Composer) | Discovered automatically from Cursor's local SQLite stores | No | | GitHub Copilot CLI | Discovered automatically by scanning the Copilot CLI session log | No | | VS Code Copilot Chat | Discovered automatically from the Copilot Chat conversation cache | No | | Cursor CLI (`cursor-agent`) | Discovered automatically by scanning `~/.cursor/chats` and `~/.cursor/projects` | No | | Cline (VS Code) | Discovered automatically from the extension's task history | No | | Cline CLI | Discovered automatically by scanning `~/.cline/data/sessions` | No | | Devin | Discovered automatically from a local SQLite database (requires Node 22.13+) | No | | Antigravity | Discovered automatically from a local SQLite database (requires Node 22.13+) | No | | Kimi Code CLI | Discovered automatically by scanning `~/.kimi-code/sessions` | No | **2. Check your credentials.** Memory needs a credential to generate summaries. Run `jolli status` (or check the Status panel). If nothing is configured, set one: ```bash # Sign in with Jolli jolli auth login # Or bring your own Anthropic key jolli configure --set apiKey=sk-ant-api03-... ``` With no credential, `doctor` reports `Config: no credentials`, and the log shows `No LLM provider available.` **3. Confirm hooks are installed.** If `doctor` reports `Git hooks: not installed`, run `jolli enable` from the repo root, then commit again. **4. Confirm a supported agent was running.** A Memory is built from a conversation transcript. If you committed without one of the fourteen supported sources (see the table above) active in that repo, there is nothing to summarize. Every source except Claude Code, Gemini CLI, and Hermes Agent on macOS and Linux is discovered automatically, so no hook or restart is needed for them, but the agent does need to have produced a session. **5. Check the queue.** If everything above is fine, the background worker may be stuck. See the next section. For deeper diagnosis, open the log. In VS Code, use **View -> Output -> Jolli Memory**. Common messages: | Message | Meaning | | --- | --- | | `No LLM provider available.` | No credential is set. Sign in or add an API key. | | `LLM proxy request failed with status 429` | Rate limited. Memory retries once within a few seconds; if that also fails it saves a placeholder summary you can refill later by clicking Regenerate on that commit. | | `LLM direct request to api.anthropic.com failed` | Your Anthropic key is invalid or rate limited. | ### Your repository uses Husky, lefthook, or pre-commit This one is worth checking early, because everything looks healthy while nothing is captured. `jolli doctor` reports `Git hooks: installed`, `jolli status` looks normal, and no error appears anywhere - but no commit ever produces a Memory. Jolli installs its hooks into the repository's `.git/hooks` directory. Some hook managers - Husky, lefthook, and pre-commit among them - point git at a directory of their own instead, and git then runs only that directory. Jolli's hooks are still on disk, which is why the checks pass; git simply never calls them. Check whether that is what is happening: ```bash git config core.hooksPath ``` If it prints nothing, this is not your problem. If it prints a path such as `.husky`, git is reading that directory rather than `.git/hooks`. You have two ways forward. If you do not need the other hook manager in this repository, remove the redirect and re-run `jolli enable`: ```bash git config --unset core.hooksPath jolli enable ``` If you want to keep it, call Jolli from the hooks it manages. Add this line to the manager's `post-commit`, `post-rewrite`, `prepare-commit-msg`, `post-merge`, and `pre-push` hooks, passing the matching hook name each time: ```bash [ -x "$HOME/.jolli/jollimemory/run-hook" ] && "$HOME/.jolli/jollimemory/run-hook" post-commit || true ``` The guard and the trailing `|| true` are deliberate: they keep a missing dispatcher or a Jolli-side error from failing your commit. `prepare-commit-msg` also needs the arguments git passes it, so forward them with `"$@"`. Commit again afterwards and run `jolli view` to confirm a Memory appeared. ### Stuck or backlogged queue A stuck lock, or a backlog of queued summaries, usually means the worker crashed or the LLM provider was unreachable for a while. ```bash jolli doctor # Reports lock state and queue size jolli doctor --fix # Releases a stale lock jolli queue-status # Reports whether summary generation is still running jolli clean --dry-run # Previews expired data that can be removed jolli clean # Removes expired sessions, queue entries, and squash markers ``` For a backlog, just make one more commit. The worker picks up where it left off and processes the rest from that point. `jolli clean` only removes expired auxiliary data: session entries older than 48 hours, queue entries older than 7 days, and stale squash markers older than 48 hours. Your stored Memories and transcripts are never deleted by `clean`. In a non-interactive shell (CI, pipes, redirected input) `clean` refuses to delete unless you pass `-y` or `--yes`, so nothing is wiped by accident. ### Sign-in failures If the browser callback page shows an error, match the code below. | Code | Meaning | What to do | | --- | --- | --- | | `oauth_failed` | The OAuth flow failed. | Retry. If it persists, use BYOK instead. | | `session_missing` | The sign-in session expired or was lost. | Retry the sign-in. | | `invalid_provider` | The authentication provider was rejected. | Retry. If it persists, contact support. | | `auth_fetch_failed` | Jolli could not fetch your user info from the provider. | Retry. | | `no_verified_emails` | Your Jolli account has no verified email. | Verify an email on your account, then retry. | | `server_error` | An unexpected server error occurred. | Wait a moment and retry. | | `failed_to_get_token` | Jolli could not retrieve your credentials. | Retry. Fall back to BYOK if it persists. | | `user_denied` | Sign-in was cancelled. | Run `jolli auth login` (or Sign In again) to retry. | | `invalid_callback` | The server rejected the sign-in callback. | Retry. | | State mismatch | The callback did not match the flow you started (shown as "Invalid sign-in callback (state mismatch)"). | Retry the sign-in from the same machine. | If you see "Could not derive Jolli site URL from API key", your Jolli API key is malformed or incomplete. Regenerate it at **Settings -> Jolli Memory -> Create Key** and sign in again. BYOK is always a fallback: if sign-in keeps failing, add an Anthropic key with `jolli configure --set apiKey=sk-ant-api03-...` and you can still generate Memories (you just cannot use Share in Jolli without a Jolli key). ### Signing in again replaced the key my other machine was using Signing in from the CLI or an editor creates an API key for you automatically. Because the sign-in has no way to hand you a key you already hold, it replaces the previous one instead: the old key is deleted and a fresh one issued. Whether that affects another machine depends on the client. Clients that identify the device get a key of their own per device, so two machines do not interfere. Clients that do not send a device name share a single key, and signing in on the second machine invalidates the first. The fix is the same either way: sign in again on the machine that stopped working. Keys you created yourself under **Settings → Jolli Memory** are never touched by this, so use one of those if you need a credential that stays put. ### Share in Jolli failures Share in Jolli posts a commit's summary to your Jolli Space. When it fails, the HTTP status tells you why. | Status | Meaning | What to do | | --- | --- | --- | | 426 | Your extension or CLI is older than the server requires ("Plugin Outdated"). | Update the VS Code or IntelliJ extension, or the CLI, to the latest version. | | 412 | This repo is not yet linked to a Jolli Space (`binding_required`). | Complete the Share flow, which prompts you to link the repo to a Space first. | | 409 | The repo is already linked to a Space (`binding_already_exists`). | No action needed. A concurrent link already won. | | 403 | The server rejected the request; the message shown comes from the server. | Usually a Jolli API key issued for a different tenant or org, or revoked access. Run `jolli auth status`, then re-authenticate. | To check which workspace you are signed in to: ```bash jolli auth status ``` If you are not signed in at all, Share asks you to sign in or add a Jolli API key first (in VS Code the button warns "Please configure your Jolli API Key first"; the CLI `jolli push` reports "Not signed in to Jolli"). Run `jolli auth login`, or paste a Jolli API key in the Settings panel. A BYOK-only setup (Anthropic key, no Jolli account) cannot use Share in Jolli. Note: a 429 (rate limit) is not a Share error. It comes from summary generation through the Jolli LLM proxy. Memory retries the summary once within a few seconds; if that retry also fails, it saves a placeholder summary that you can refill later by clicking Regenerate on that commit. ### MCP tools not appearing If your AI agent does not show the Jolli Memory tools (`search`, `recall`, and the rest), check these in order. 1. **Did enable run?** MCP registration happens during `jolli enable`. Run `jolli status` to confirm Jolli is enabled in this repo. 2. **Is the server registered for your host?** `.mcp.json` in your project root is where `jolli enable` writes the `jollimemory` server for **Claude Code** (and Copilot CLI). Other hosts use their own config: Cursor reads `.cursor/mcp.json`, and Gemini, Codex, OpenCode, VS Code Copilot Chat, Cline, Devin, Antigravity, Kimi Code CLI, and Hermes Agent each read a machine-wide file (see the host table in [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp)). Confirm the file for *your* host exists and contains the entry. 3. **Was the agent installed before you enabled?** Registration runs only during an explicit `jolli enable`; it does not retry on later sessions. If you installed the agent after enabling, run `jolli enable` again. 4. **Restart your host.** Your agent reads `.mcp.json` at startup, so restart it (or reload the window) after enabling. 5. **Check that the config file is valid JSON.** If the file already exists but cannot be parsed, Jolli leaves it completely alone rather than risk overwriting your other servers, so that one host is skipped while `jolli enable` still reports success. Nothing appears on screen; the reason is written to `.jolli/jollimemory/debug.log` in the repo, as a line beginning `Skipping MCP registration`. Open your host's config file, fix the syntax (a trailing comma is the usual culprit), and run `jolli enable` again. An empty file is fine and is treated as a fresh start. Codex is the exception: its config is TOML and Jolli edits only its own block, so a syntax error elsewhere in the file does not stop registration. Codex is skipped only when the file cannot be read at all, such as a permissions problem, logged as `Skipping Codex MCP`. If the tools appear but search returns nothing or looks stale, rebuild the local search index: ```bash jolli mcp --reindex ``` `--reindex` rebuilds the search index only. It does not register the server or refresh the tool list, so if tools are missing entirely, the fix is in steps 1 to 3 above, not here. For the full list of tools and how each host connects, see [Use Your Memory from Any AI Agent (MCP)](https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp). ### Turning Jolli Memory off for a repository Sometimes a repository should not be recorded at all. To turn Memory off for one: ```bash jolli disable ``` This removes the git hooks and records the choice against the repository, so it stays off. It prints `Jolli Memory disabled. Hooks removed.` when it worked. Turn it back on with `jolli enable`, which clears the choice along with reinstalling everything. Five things are worth knowing before you rely on it: - **It also keeps the repository out of session-statistics uploads, permanently.** What the repository recorded before you disabled it is not uploaded later either. Other repositories on the machine keep syncing theirs. - **`jolli disable --integrations-only` is not a way to turn Memory off.** It removes only the repo's MCP registration and deliberately leaves hooks, skills, and the recorded choice alone. Use plain `jolli disable` if you want the repository left alone. - **If the choice cannot be written down, nothing is removed.** Rather than take the hooks out and risk a later upgrade quietly switching Memory back on, `disable` stops and tells you, leaving the repository as it was. If you see that, fix the reported problem and run it again. - **The choice is recorded per repository, and it survives.** Every worktree of the repository shares it, and automatic setup (including the Claude Code plugin's, which runs on every session) will not override it. Only `jolli enable` clears it. - **Jolli's tools may still appear in your agent afterwards, and that is expected.** `disable` removes the MCP registration that belongs to this repository, which is the entry for Claude Code and Cursor. The other hosts share a single machine-wide entry across every repository you use, so removing it here would break Jolli for all of them; it is left in place deliberately. The tools stay listed, and they simply return nothing for a repository that is turned off. In IntelliJ the **Pause Jolli Memory** checkbox in Settings does the same thing, and unpausing re-enables in the same way. One limitation to be aware of with **git submodules**: the choice is stored per super-repository rather than per submodule, so turning Memory off inside one submodule turns it off for the other submodules of the same super-repository. Nothing is lost, and you can turn it back on from any of them, but it is wider than it looks. ### Missing Memory Bank Markdown files If a visible `.md` file in your Memory Bank folder was deleted (by you or another tool), restore it: ```bash jolli heal-folder ``` This re-renders the missing Markdown from the hidden canonical JSON that Jolli keeps alongside it. It does not call the LLM and does not re-summarize anything, so it is fast and free. Your Memories on the orphan branch are the source of truth and stay intact either way. Healing works only when your storage is in dual-write or folder mode (the default is dual-write). If the repo is set to orphan-only storage, there are no visible Markdown files to heal, and the command tells you so. ### Still stuck File an issue at support@jolli.ai and include your `jolli doctor` output. That output captures your hook, credential, lock, and queue state, which is exactly what we need to help. ## Part 2: FAQ ### Will Jolli Memory slow down my commits? No. Your commit returns immediately. The git hook enqueues the work and hands it to a background worker, then gets out of the way. The summary is generated in a detached process and appears in your editor shortly after, usually within about 10 to 20 seconds. If a summary call fails, it retries once after a short delay, then saves a minimal record so nothing downstream breaks. ### Does Jolli Memory send my code anywhere? Your code stays private by default. Here is exactly what happens: - Your transcripts stay on your machine by default. They are uploaded only if you turn on `syncTranscripts` for Memory Bank cloud sync (or run `jolli sync-memory-bank --transcripts`); they are never sent on Share in Jolli. - To build a summary, your transcript and git diff are sent to the LLM. Either directly to Anthropic (when you use your own Anthropic key) or through the Jolli LLM proxy (when you signed in with Jolli). The proxy holds the payload in memory only for the request and never stores it or writes it to a log. - Only the generated summary is saved, and it is saved locally. It leaves your machine when you click Share in Jolli, and then the summary (plus a structured JSON copy), the commit hash, branch, commit author, date, change stats, the changed-file paths, any extracted references (Linear, Jira, GitHub, Notion, Confluence, Asana, monday.com, Slack, Zoom, Vercel, Figma, Sentry, and Context7 library lookups), your repository's remote URL, and any attached plans and notes are sent. Raw transcripts and the raw diff are never sent to a Jolli Space. - **Statistics about your AI sessions are a separate channel, and it is on when you are signed in.** It sends usage figures and tool names, not conversation text, and unlike everything above it covers every repository Jolli is enabled in rather than only the ones you shared. See **Does Jolli upload statistics about my AI sessions?** below for what it carries and how to turn it off. ### Does it work offline? Mostly. Your commit and your local Memory storage work fully offline, because the commit hook and the on-disk storage do not need the network. Only summary generation needs the network, since it calls the LLM. If you commit while offline, the worker records a minimal entry and the summary fills in later. Make one more commit once you are back online and the worker processes the backlog. ### Does it work with monorepos and git worktrees? Yes to both. Jolli Memory is worktree-aware: hooks and summaries work across `git worktree` checkouts, and each worktree tracks its own current branch so its Memories stay consistent. A monorepo is just one repository, so it works normally. One Memory Bank folder can also hold many repositories, each in its own subfolder. ### How do I see what Jolli has captured? Several ways, depending on where you are: - **In the editor sidebar (Current Branch view).** The **Committed Memories** section lists every commit's Memory; click the eye icon on one to open it: a Quick recap and per-topic cards with **Why this change**, **Decisions behind the code**, and **What was implemented** callouts, plus Conversations, Context, and Files panels. The **Working Memory** block above it shows what will go into your *next* commit's Memory before you commit, so you can see (and adjust) what is being captured. - **In the Memory Bank.** The Memory Bank view browses every stored Memory across branches and repos, with search and a Tree / Timeline toggle. Because the Memory Bank is also plain Markdown on disk (default `~/Documents/jolli//`), you can open and read it with any tool, no extension required. See [Memory Bank and Sync](https://docs.jolli.ai/jolli-memory/memory-bank-and-sync). - **From the CLI.** ```bash jolli view # compact list of recent memories jolli view --commit 1 # the latest commit's full Memory jolli view --commit # any commit by hash prefix jolli status # which agents and sessions Jolli detected jolli recall # the current branch's compiled context ``` ### What is stored where? | Data | Where it lives | Leaves your machine? | | --- | --- | --- | | Raw transcripts | Orphan branch and Memory Bank folder (both local) | Only if you enable `syncTranscripts` (Memory Bank cloud sync); never on Share in Jolli | | Git diff | Sent to the LLM at summary time | Not stored by Jolli, discarded after the summary is made | | Generated summaries | Orphan branch and Memory Bank folder (both local) | Only when you click Share in Jolli | | Session metadata | Project `.jolli/jollimemory/` (local, gitignored) | No | | Plans and notes | Local, attached to commits | Only the attached ones, on Share in Jolli | | Usage telemetry | Local buffer, flushed in small batches | Yes; content-free, and attributable to your account only when signed in | | Session statistics | Your machine's dashboard database | Yes when you are signed in, for every enabled repository; turn it off with `syncSessions`. See the entry below | The orphan branch (`jollimemory/summaries/v3`) is the source of truth and is completely separate from your code history. See [Memory Bank and Sync](https://docs.jolli.ai/jolli-memory/memory-bank-and-sync) for how the folder is laid out. ### Is telemetry on, and can I turn it off? Usage telemetry is on by default. It is content-free: event names, surface and version, OS and Node version, CPU architecture, a deployment-tier tag, a timestamp, a random install ID, and coarse counts. It never includes your code, file paths, commit messages, diffs, transcripts, Memory content, or repo or branch names. The payload carries no account identifier; note that when you are signed in to Jolli, events upload with your Jolli key, so the server can associate them with your account at ingest. BYOK or signed-out setups upload with no key and stay unattributed. Events also carry which AI tool the work happened in, when that is known: one name from a fixed list (`claude`, `codex`, `gemini`, `opencode`, `cursor`, `cursor-cli`, `copilot`, `copilot-chat`, `cline`, `cline-cli`, `devin`, `antigravity`, `kimi`, `hermes`) and nothing else - not identity, not content, not a path. When the tool cannot be determined the field is left out rather than guessed, so a missing value means "not measured" and never "the CLI". Events from clients older than 0.99.14 carry it not at all, and nothing fills it in after the fact. Telemetry is separate from **session statistics**, which are not content-free and have their own switch. See the next entry. Turn it off any time with either of these: ```bash # Persisted opt-out jolli telemetry off # Or the standard environment variable export DO_NOT_TRACK=1 ``` Check the current state with `jolli telemetry status`, and see exactly what would be sent with `jolli telemetry inspect`. ### Does Jolli upload statistics about my AI sessions? Yes, when you are signed in. Session statistics are what fill the web dashboard: session counts and durations, models used, token counts, estimated cost, and tool and skill names (including the names of any MCP servers you use). They also carry each session's **title**, and many AI tools use your first message as the title. Conversation text, your code, diffs, tool arguments and Memory content are never part of it. **Your memory search queries go up too** - the words you type into `jolli search` - because the dashboard's Top Search Terms card is built from them. This is free text you wrote, so it is worth knowing about even though the searches themselves are not conversation content. **The scope is wider than anything else here.** Everything else in this section leaves your machine only for a repository you chose to share. Session statistics go up for **every repository Jolli is enabled in on this machine**, connected to a Space or not, whatever the per-repository push switches say: your API key alone says which organization they belong to. **Turning it off**, whole machine, persisted: ```bash jolli configure --set syncSessions=false ``` Or open `jolli dashboard` and use **Settings → Sync to Jolli → Sync session statistics**, under the heading **Session statistics — for the whole machine**, which applies immediately. The editor extensions do not carry this switch, so in VS Code or IntelliJ use the command above. To leave one repository out, `jolli disable` there keeps it out for good, including whatever it recorded beforehand. See **Turning Jolli Memory off for a repository** above. **If nothing is arriving:** uploads need you signed in, need Node 22.13 or later (they read the dashboard's database), and are throttled so several open projects do not each push the same rows. Push what is waiting with `jolli doctor --sync-sessions`. ### Is my content used to train AI models? No. Jolli's [Privacy Policy](https://www.jolli.ai/privacy) states that your personal information, inputs and data are not used, and not allowed to be used, to train third-party foundational AI models, and says the same specifically of Jolli Memory content. Generating a summary does send your transcript and diff to the LLM, and nothing about that step retains them - see **What is stored where?** above for how the request is handled. ### Where is my data stored? In the United States. The Privacy Policy states that all data is stored and processed in the US, and that sub-processors process data in their own US-based infrastructure. Anthropic is named there as an AI service provider. Remember that most of Jolli Memory never leaves your machine at all: summaries and transcripts live on the git orphan branch and in your Memory Bank folder, and only travel when you Share to a Space or turn on Memory Bank sync. See **What is stored where?** above. ### Is my data encrypted? Yes, in transit and at rest. Connections use HTTPS/TLS. The Privacy Policy lists AES-256 encryption for stored data, including server-side AES-256 on object storage and AES-256-GCM for API keys, tokens, and any personal information appearing in audit logs. ### Where do I find your security and compliance documentation? For certifications, sub-processor lists, retention commitments from our AI providers, and anything you need for a vendor review, email [support@jolli.ai](mailto:support@jolli.ai). The [Privacy Policy](https://www.jolli.ai/privacy) and [Terms of Service](https://www.jolli.ai/terms) cover data handling. ## Related - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, sign in, and your first Memory. - [Reference](https://docs.jolli.ai/jolli-memory/reference) - config keys, commands, and recovery paths. - [Supported AI Agents and Capture](https://docs.jolli.ai/jolli-memory/supported-ai-agents-and-capture) - why a session might not be captured. --- # Use Your Memory from Any AI Agent (MCP) Source: https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-agent-mcp ## Overview Jolli Memory captures the reasoning behind your commits. This page connects that memory to your AI agent through the Model Context Protocol (MCP), so the agent can read your history from inside the chat. No terminal, no copy-paste. Ask "what did we decide about auth?" or "recall this branch," and the agent answers from your real stored Memories instead of guessing. ## Prerequisites - Install your agent **first**, then run `jolli enable` in the repository - enable registers the MCP server with whichever agents it finds. - **Restart the agent** afterwards. A session that was already running will not see the new server. - At least one commit with a Memory, so there is something to ask about. - For the hosted endpoint: a `sk-jol-` API key or a browser sign-in. An org admin can turn the MCP surface off entirely. ## What you get Enabling Jolli exposes a set of tools to your AI agent. Most are read-only; a couple write on your behalf (`push_memory` and `bind_space` publish to and bind a Jolli Space, covered below). Four read tools cover the everyday "remember what we did" job: - **search** - Ask "have we handled rate limiting before?" and the agent searches every branch's Memories for the answer. - **recall** - Ask it to recall a branch and it loads that branch's full context: decisions, plans, notes, and commits. - **get_decision_timeline** - Ask how a decision evolved and it traces that topic across commits, oldest first. - **list_branches** - Ask which branches have Memories and it lists them with their topics. You ask in plain language. The agent picks the tool and answers in the chat. Also available: **get_pr_description** and **queue_status** power the pull-request workflow (see Create PR in [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory)); **bind_space**, **list_spaces**, and **push_memory** back Share in Jolli (see [Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces)); and **status** reports the health of your Jolli setup for this repo - which hooks are installed, your hook runtime, account and API-key configuration, detected AI integrations, and your stored-Memory count. You never call these by name; your agent reaches for them when the task calls for it. When you are signed in, the server may also register additional Jolli-hosted tools defined by the backend, so your agent can see more than the built-ins listed above. Set `mcpPlatformToolsEnabled` to `false` for a built-ins-only server. ## Automatic setup Jolli's MCP server is **CLI-hosted**: a local stdio process - `jolli mcp` - that each host spawns on your own machine and talks to over standard input and output, registered under the server key `jollimemory`. It reads the Memories stored with your repo, on your machine. That is the right server for an agent that runs on your own machine. For an agent that cannot spawn a local process, Jolli also serves a hosted endpoint over the web - see [Connect a hosted agent](#connect-a-hosted-agent) below. There is no separate MCP install. When you enable Jolli in a repo, the `jollimemory` server is registered for you into every supported AI host that Jolli detects on your machine: | Host | Where it's configured | | ---- | --------------------- | | Claude Code | `.mcp.json` in the repo | | Cursor | `.cursor/mcp.json` in the repo | | Gemini CLI | `~/.gemini/settings.json` | | Codex CLI | `~/.codex/config.toml` | | OpenCode | `~/.config/opencode/opencode.json` | | GitHub Copilot CLI | `~/.copilot/mcp-config.json` | | VS Code Copilot Chat | the VS Code user folder's `User/mcp.json` | | Cline (VS Code extension) | `/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json` | | Devin | `~/.config/devin/config.json` | | Antigravity | `~/.gemini/config/mcp_config.json` | | Kimi Code CLI | `~/.kimi-code/mcp.json` (or `$KIMI_CODE_HOME/mcp.json`) | | Hermes Agent | `~/.hermes/config.yaml` (or `$HERMES_HOME/config.yaml`), under `mcp_servers` | Claude Code and Cursor are configured per repo. The other ten share one machine-wide config. Three of these are easy to mistake for something else. **Antigravity** reads `~/.gemini/config/mcp_config.json`, which is a different file from the Gemini CLI's `~/.gemini/settings.json` even though both sit under `~/.gemini/`; the per-variant `mcp_config.json` files point back to that one. For **Cline** it is the VS Code extension that is wired up, once per VS Code flavor you have installed - the Cline CLI keeps no MCP config of its own, so there is nothing to register for it. And **Kimi Code** keeps its MCP servers in `mcp.json`, not in the `config.toml` next to it, so a server added to the TOML file will not be found. **Hermes** is the one host with more than one config file to keep straight: if you use `hermes profile` to run isolated homes, each has its own `config.yaml`, and Jolli registers itself into every one of them rather than only the default. A host is wired up only if Jolli detects it when you run `jolli enable`, and registration does not repeat on its own afterwards. So install the agent first, then run `jolli enable`. If you add one later, run `jolli enable` again to register it. Every Jolli surface registers the server: - **CLI** - `jolli enable` from the repo root. - **VS Code extension** (including forks such as Cursor and Windsurf) - **Enable Jolli Memory** in the Status panel. - **JetBrains plugin** - **Enable** in the tool window. It needs Node.js on your PATH for the MCP server and for both skills; the plugin sets them up by running its bundled CLI. Without Node, those are skipped cleanly and the tool window shows "MCP & Skills: Node.js not found." Both `/jolli-recall` and `/jolli-search` are unavailable until Node is installed, and the tool window says so. Memory generation keeps working through the plugin's native Java hooks. - **Claude Code, Cursor and Codex plugins** - each registers Memory's MCP tools itself. On Cursor the server is written once you opt the repository in, and it registers disconnected, so enable `jollimemory` in **Customize**. See [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). ### Any other MCP host Only those twelve hosts are auto-registered, but the `jollimemory` server is a standard stdio MCP server, so any MCP-capable host can use it. Register it by hand with command `jolli` and args `["mcp"]`, or point the host at `npx -y @jolli.ai/cli mcp` if you have nothing installed. [Install Jolli Memory](https://docs.jolli.ai/jolli-memory/install-jolli-memory) covers both routes and what each one can do. ## Connect a hosted agent Everything above spawns `jolli mcp` locally. An agent that runs somewhere else - a hosted agent, an automation platform, anything that cannot start a process on your machine - connects to Jolli over the web instead. Point it at **`https://jolli.ai/mcp`**, as a **Streamable HTTP** MCP server. There are two ways to prove who you are. ### Sign in from the agent If your agent supports connectors that sign in for themselves, this is the better option. Add it as a connector and the agent sends you to Jolli in your browser, where you approve the connection and it returns with access. - **You choose which organization it reaches.** The approval screen asks, and it checks your answer against the organizations you currently belong to. This is the practical difference from a key: if you belong to more than one organization, approving is where you say which one, rather than finding out afterwards. - **Only the organizations where this kind of connection is switched on are offered.** If none of yours are, the screen tells you so - "None of your workspaces have this kind of connection turned on yet. Ask an administrator to enable it, then try again." - rather than letting you approve into somewhere that would then refuse every request. This is a different message from the one you get when you belong to no active organization at all, because only this one is something an administrator can fix. - **Approving also finishes setting up your account** in that organization if you were invited and have not opened it yet. Without that step an agent would connect successfully and then find nothing, which looks the same as an empty workspace. - **Nothing is shared until you approve**, and you can approve again later for a different organization. If your agent connects but every request comes back refused, it most likely asked for no permissions when it sent you to approve. Jolli tells it which permission to ask for, and a connector that follows the standard will send you through approval once more and then work. Approving again is the fix. ### An API key For anything that cannot open a browser, authenticate with a Jolli API key as a bearer token: ``` POST https://jolli.ai/mcp Authorization: Bearer sk-jol-... ``` - **The key decides which workspace you reach**, so there is nothing else to configure and no workspace name anywhere in the URL. - Create the key under **Settings → Jolli Memory**. It needs the MCP scope, which every API key carries while MCP is enabled for the organization (see the Prerequisites above for the organization-wide switch). ### What a hosted agent can read Over this endpoint an agent can read your organization's **memory** as well as your documentation: | Tool | What it does | | ---- | ------------ | | `search_remote_memory` | Search your organization's memory - the commit summaries, plans, and notes recorded from your team's work - across every memory space the key's creator can access. Optionally restrict it to one memory space. | | `get_remote_memory_content` | Fetch the content of one memory document by its JRN. | Both are scoped to what the key's creator is allowed to view; a search that reaches further silently drops what they cannot see. Personal Spaces and deleted Articles are never returned. Search results carry a browsable link, a plain-text snippet of the match with the highlight markup taken out, and a relevance score, so an agent can cite what it found rather than only quote it. A search spanning several Spaces is ranked by relevance before it is capped, so the best matches survive the cap rather than whichever Spaces happened to be read first. ### Writing a memory from a conversation | Tool | What it does | | ---- | ------------ | | `create_remote_memory` | Create a new memory in a Jolli Memory space: a decision, a summary, or a note captured without leaving the conversation. | This is the one tool on this surface that writes. A few things govern where it lands and whether it is allowed: - **Where it goes.** Pass a space id to choose the target, or leave it out and it writes to your organization's default memory space. If your organization has no default and you name none, the call fails and creates nothing. It never creates a space for you: make one in the web app, and that choice becomes the default for later writes. - **Memory spaces only.** Documentation spaces and personal spaces are refused. The refusal reads the same whatever the reason, so the tool cannot be used to work out which spaces exist. - **What actually gates it** is the per-space contribution permission of the person who created the API key. If they cannot contribute to the target space, neither can the agent. - **Repeating a create updates rather than duplicates**, so an agent that retries does not leave two copies behind. - Memories written this way are grouped separately from the ones your repositories push, and kept per author, so two people capturing the same title do not collide. The documentation tools still leave memory and personal Spaces out, so pointing an agent at documentation does not quietly hand it your team's memory, and the reverse holds too. They are: | Tool | What it does | | ---- | ------------ | | `list_remote_spaces` | List the documentation spaces you can access, with each space's id, name, slug, and description. | | `search_remote_articles` | Search article titles and content across the spaces you can access. Results include browsable URLs, bounded match snippets, and relevance scores. Optionally restrict the search to a single space by id. | | `get_remote_article_content` | Fetch the current published content of one article you can access, identified by its JRN. | For the older REST endpoints, see [Settings](https://docs.jolli.ai/settings). ### The rest of the endpoint Memory and documentation are the tools most people come here for, but they are not the whole surface. A connected agent also gets repository reads and Workflow control. Worth reading before you authorize an agent, since browser approval hands it everything below at once. **Reading a connected repository.** Available to any authorized agent, scoped to what the key's creator can reach. | Tool | What it does | | ---- | ------------ | | `browse_remote_repo_tree` | List a directory's immediate children. Not recursive. | | `read_remote_repo_file` | Read one file's contents as text. | | `search_remote_repo` | Search file contents. Public repositories return matching lines with line numbers; private ones return file-level matches only. | | `get_remote_repo_diff` | Diff two branches, tags, or commits. On a public repository only the most recent hundred or so commits are reachable. | | `get_remote_repo_commits` | Recent commit history, optionally filtered to a path. | | `list_remote_folder_contents` | Browse folders and Articles inside a Space, one level at a time. | **Workflows.** These need Workflows to be enabled for your organization. | Tool | What it does | | ---- | ------------ | | `list_workflow_definitions` | The Workflow types available, each with its prompt-template variables. | | `list_workflows` | The Workflows you can see. | | `get_workflow` | One Workflow, with its sources, configuration, and destination. | | `list_workflow_runs` | A Workflow's run history, newest first. | | `get_run_status` | The status of a single run. | | `run_remote_workflow` | Start a server-side run of a Workflow you're allowed to run. | | `cancel_remote_workflow` | Cancel a run in flight. | **Running a Workflow on your own machine.** Four tools drive a local run end to end, which is how the CLI recipes work: `start_local_run` takes the Workflow id and hands back the plan and the branch to write into, `report_local_run_progress` keeps the run alive while the work happens, and `complete_local_run` or `abandon_local_run` closes it out - the first with the pull request number, the second releasing the lock so the Workflow can run again. The two run-control tools and the four local-run tools **act**, they don't just read. Everything else on this page reads. Permission is checked when the call is made, against what the person behind the credential is allowed to do, so an agent can never run a Workflow its key's creator couldn't run by hand. ## Turn it on and verify 1. Enable Jolli in your repo (see above) and make sure the repo has at least one commit with a Memory. 2. **Restart your AI agent.** This is the step people miss. An agent reads its MCP config at startup, so a session that was already running will not see the new server until you restart or reload it. In VS Code (or a fork such as Cursor or Windsurf), reload the window; in a JetBrains IDE, restart it; for a CLI agent, quit and reopen. 3. Ask the agent to use it: - "Recall this branch." - "What did we decide about the caching layer?" - "Have we dealt with duplicate webhook deliveries before?" If it answers with specifics grounded in your commits, you are set. On Claude Code the tools appear namespaced as `mcp__jollimemory__search`, `mcp__jollimemory__recall`, and so on. Other hosts list them under a `jollimemory` server. You rarely need the exact names; plain language is enough. ## Skills vs tools Alongside the MCP tools, `jolli enable` installs guided skills. On Claude Code they are slash commands; on other hosts they are Agent Skills. They call the MCP tools for you (and fall back to the CLI when a host has no MCP support), so they are the easy front door: - **/jolli:recall** - deep on one branch. Loads that branch's full Memory and synthesizes an answer. Use it to resume or understand a specific branch. - **/jolli:search** - broad and shallow across every branch. Returns relevance-ranked hits. Use it to find where something was decided. Those are the names in Claude Code, where the plugin owns the `/jolli:*` namespace. The Cursor plugin uses `/jolli-recall` and the Codex plugin uses `$jolli:recall` - see [Jolli Memory in Your AI Agent](https://docs.jolli.ai/jolli-memory/jolli-memory-in-your-ai-agent). Where the CLI installs the skills itself instead (Gemini CLI, GitHub Copilot, OpenCode, and Codex or Cursor without the plugin) they are unnamespaced, as `/jolli-recall` and `/jolli-search`. `jolli enable` installs three more alongside them, into the same place: - **`/jolli`** on its own opens a menu of the Jolli actions available in that session and runs the one you pick. Claude Code has its own version of this menu; every other host gets it from the CLI. - **`/jolli-local-run`** and **`/jolli-remote-run`** run a Jolli Workflow from your agent, on your machine or on Jolli's backend. See [Reference](https://docs.jolli.ai/jolli-memory/reference) for what they need. All five are written to one shared location, so any agent that reads Agent Skills from your project picks them up. There is no per-host skill setting. Rule of thumb: search to find the branch, recall to go deep on it. ## Troubleshooting **The tools do not show up.** - Restart the agent. Its MCP config is read at startup (see above). - Check that your agent is one of the eleven supported hosts listed under Automatic setup. If it was not installed when you ran enable, install it, then run `jolli enable` again. Registration only happens during an explicit `jolli enable`, so a host added afterwards stays unregistered until you re-run it. - IntelliJ only: confirm Node.js is on your PATH, then reopen the project to retry. The tool window's "MCP & Skills" row reports the current state. **Some tools are there and others are missing.** The tools that answer for a repository are hidden when the server was started outside a project, which some editors do. Rather than answering with an empty result that reads as "there are no memories here", they do not appear at all. Listing your Jolli Spaces and your workspace's own platform tools do not depend on a repository, so they still work. Reopen the agent on the project folder to get the rest back. **Several open sessions.** Sessions working in the same checkout share one Jolli MCP server rather than each starting its own, so opening more of them costs less than it used to. Nothing about how your agent talks to Jolli changes. If you need each session to run its own server, set `JOLLI_MCP_NO_DAEMON=1` in the environment your agent starts in. **Search results look stale or empty.** The search index is a disposable local cache, separate from your stored Memories. Rebuild it: ```bash jolli mcp --reindex ``` It reindexes from your stored Memories and prints how many documents it loaded. For anything else, run `jolli doctor` and see the troubleshooting section in [Reference](https://docs.jolli.ai/jolli-memory/reference). ## Next steps - [Getting Started with Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory) - install, enable, and your first Memory. - [Reference](https://docs.jolli.ai/jolli-memory/reference) - the MCP tool list, config keys, and CLI commands. - [Recall vs Search](https://docs.jolli.ai/jolli-memory/recall-vs-search) - what recall and search do, and when to reach for each. --- # Editing Source: https://docs.jolli.ai/jolli-spaces/editing ## Overview The manual writing surface: the Article editor and the tools for finding and organizing content within a Space. For the AI side - drafting with the Agent, Changesets, and Gap Analysis - see [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent). ## Prerequisites - **Contributor access or above** to the Space. A Viewer can read Articles and comment threads but cannot edit, post, reply, or resolve. - An existing Space with Articles to work on. ## The editor Click any Article to open it. Standard Markdown syntax (`#`, `**bold**`, `[link](url)`) renders live. Folders open the same editor - a Folder can hold its own content. ### Floating toolbar Select text and a small toolbar floats above the selection: bold, italic, underline, strikethrough, inline code, link, blockquote, headings H1–H4, paragraph reset. The toolbar only appears with a selection - nothing always-on at the top of the editor. There are no list or table buttons. Use Markdown directly (`-` for a list, pipes for a table); the editor renders them live. ### Auto-save Every edit auto-saves about two seconds after you stop typing - there's no Save button. Live multi-user editing isn't supported yet: if two people edit the same Article simultaneously, the last save wins. Use Changesets (via the Jolli Agent or Gap Analysis) for any collaborative writing flow. ### Cross-article links Type `[[` to open an inline search popover, type part of another Article's title, pick it. The link tracks the target Article - if it gets renamed, the link text updates. Cross-Space references need full URL links; the popover only searches the current Space. ### Images and uploads Drag images into the editor (PNG, JPEG, GIF, WebP; 10 MB per file). For text files, the Folder's three-dot menu has an **Upload File** option that creates an Article from the upload. Accepted formats are `.md`, `.mdx`, `.txt`, `.json`, `.yaml`, and `.yml`, up to 1 MB; the resulting Article is fully editable like any other. OpenAPI specs (JSON or YAML) are recognized automatically - drop one in and it renders as an interactive API reference page on the published Site. ### Article outline Alongside the editor is a column of small bars, one per heading, down to the fourth level. Hover it and it expands into an **On this page** list; click any entry to jump straight to that section. On a long Article it is the fastest way to move around without scrolling, and it doubles as a quick check that your heading structure reads sensibly. ### Published Sites The Article header carries a globe icon with a count next to it, showing how many Sites currently include the Article you have open. Click it and the list splits into **Public** and **Internal**, so you can tell at a glance whether what you are editing is already live and who can see it. An Article that belongs to no Site shows nothing. ### Version history Past versions are browsable from the right-side rail. You can view, copy from, or restore any of them. Restoring creates a new version with the old content; you don't lose history. Auto-save does not write a new version every time. Within **30 minutes** of the last one, your edits update that same version in place, so a long editing session lands as one entry rather than dozens. After 30 minutes the next save starts a new version. A version is also started whenever a Changeset is pending on the Article, or when the current version came from applying one. ### Delete and restore Soft-delete via the three-dot menu. Articles move to the Space's Trash and can be restored or permanently deleted from there. Folders move with everything inside them. ### Comments Every Article has a comment thread in the right-side rail. Comments are on the Article as a whole, not anchored to paragraphs - quote in your comment if you need to point at one. You can reply (one level deep), edit or delete your own comments, and @-mention a teammate to notify them. Threads update in real time, and comment activity appears in your Inbox. Commenting needs edit access to the Space. A **Viewer** can read a thread but not post, reply, or resolve; attempting it returns "Insufficient permissions to comment in this space". Contributors and above can comment, and anyone with edit access can resolve a thread or delete someone else's comment for moderation. ## Organizing ### Searching within a Space A search box sits above the Article tree. Start typing and the tree narrows to matching Articles as you go. - Search runs a short beat after you stop typing, so you don't need to press Enter. - Click the **X** in the box, or press **Esc**, to clear the search and restore the full tree. - Search is scoped to the current Space. To find something in another Space, switch to it first (or use a cross-Space URL link, covered above). ### Drafts Article drafts - new Articles you or the Jolli Agent started, plus in-progress edits to existing Articles - collect on a dedicated **drafts** page, reachable via **View all** from the drafts list. A draft is standalone until you finish it; it isn't part of the published Space yet. - Each row shows the draft title, a short content preview, when it was last edited, and who created it. - The search box filters the list by title and content (case-insensitive). - **Edit** opens the draft in the editor; the trash icon deletes it after a confirmation prompt. Deleting a draft only discards that unfinished draft - it never touches a published Article. ## Related - [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) - let the Agent draft content, and keep docs in sync with Gap Analysis. - [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space) - members, visibility, automation, and storage. - [Jolli Sites](https://docs.jolli.ai/jolli-sites) - publish the Space at a URL. --- # Getting Started with Jolli Spaces Source: https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces A Space is where documentation lives in Jolli. You bring your existing docs in (or generate them from code); the Jolli Agent and Gap Analysis keep them in sync as the code changes; every edit passes through review before going live. When you're ready to share, you publish a [Site](https://docs.jolli.ai/jolli-sites) from the Space. ## What lives in a Space - **Articles.** The core unit of content. Markdown by default; JSON content type for OpenAPI specs. - **Folders.** Group Articles. Nestable, drag-and-drop. - **Sources.** External inputs (GitHub repos) the AI reads to import, generate, and detect drift. - **Changesets.** Edits the Jolli Agent or Gap Analysis proposes, batched for review before they go live. - **The Jolli Agent.** Jolli's AI agent, in its own tab. See [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent). ### Sorting and filtering The controls above the Article tree let everyone browsing the Space narrow what they see: - **Sort** - Default (the Space's manual order), Alphabetical, Last Updated, or Created. Each has ascending/descending variants. - **Filters** - restrict to Articles updated in a window (Today / Last 7 days / Last 30 days / Last 3 months / a custom date) and/or by creator name. ## Who Spaces is for Teams and individuals. On signup, Jolli creates a **Personal Space** for you so you have a place to work right away. Jolli also provisions a ready-made **Shared Space** - seeded with a Welcome doc - so your team has somewhere to collaborate from the start. Create additional shared Spaces any time. Your first sign-in lands on **Set up Jolli for your team** rather than in a Space. That page explains how work reaches this workspace and how to install Jolli Memory; the Spaces are waiting behind it, and the sidebar takes you there whenever you want. There is a cap on how many shared Spaces an organization can have. When you reach it, creating another is refused with a message naming your limit, and you either delete a Space you no longer need or contact [support@jolli.ai](mailto:support@jolli.ai) to have the limit raised. Your Personal Space does not count toward it. ## Finding your way around ### Favorites The sidebar shows a **Spaces** section and a **Sites** section, each capped at six items so the list stays scannable. Hover any Space or Site and click the star to pin it as a favorite. - Favorites sort to the top of their section (alphabetically), then remaining slots fill with your other Spaces or Sites. - A pinned item shows a filled star; hover an unpinned one to reveal its empty star. Click again to unpin. - If you have more than six favorites in a section, all of them show and the cap is lifted. - **View all shared spaces** / **View all sites** appears only when some items are hidden by the cap - click it to open the full list. Favorites are per-section: starring a Space has no effect on the Sites list, and vice versa. Your Personal Space and any Jolli Memory Spaces (Spaces populated by [Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory), Jolli's dev-context capture tool) aren't part of the Spaces favorites list - they have their own spots in the sidebar (Jolli Memory Spaces live under the **Memory** section). ### Your Personal Space in the sidebar Your Personal Space has a fixed spot in the sidebar (the **Personal Space** entry, marked with a person icon), separate from the shared **Spaces** list. Click it to jump straight to your own private Space. - It's the single-user Space Jolli creates for you on signup - a place to draft and experiment before anything is shared. - It never appears in the shared Spaces list or its favorites, so team Spaces and your private one stay visually distinct. - If your account is deleted, Personal Spaces are removed rather than transferred to an admin (unlike shared Spaces). See [Settings](https://docs.jolli.ai/settings). ## Onboarding On first sign-in, the **Jolli Agent** runs a guided walkthrough that **generates documentation fresh from your source code**. If you already have docs, it reads them as a signal for audience and structure - but still generates from the code so the output stays current. To bring existing Markdown in **as-is** instead, use **Import from GitHub** - a connected GitHub repo, or a public repo URL (no authentication needed) - to pull `.md` files straight into a Space. Once you kick off generation, Jolli creates a new Space and offers next steps, such as creating a Site from it. ### Creating a Space after the first one Every Space you create later starts from the same dialog, which opens with **How would you like to get started?** and three choices: | Choice | What it does | |---|---| | **Use your own repository as content storage** | Content lives in your own GitHub repository. The Space is created first, then you connect the repository on its **Storage** tab. This is the default when it is available. | | **Guided setup** | Connect a repository and generate documentation from it, the same walkthrough as first sign-in. Adds two steps: pick the repository, then choose whether to import existing Markdown or generate from the code. | | **Start from scratch** | An empty shared Space. Pick this when you intend to write in Jolli rather than mirror a repository. | The first option is the one to choose if the repository should stay the source of truth, since that is what enables git-backed publishing and pull-request review. See [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space) for the Storage tab, and [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) for how generated content is reviewed. ### What the import does For a typical docs folder (dozens of files), expect a few minutes. The Agent: - Preserves your folder structure where it makes sense. - Imports Markdown only (`.md` / `.mdx`). Other formats - RST, AsciiDoc, Textile, and anything non-Markdown - are skipped. - Flags issues it finds for you to resolve, rather than silently rewriting them (see below). Two things the import does **not** do automatically - the Jolli Agent offers each as a follow-up step: - **Images.** Imported images still point back to the source repository, so your published Site depends on it staying available. The Agent can re-upload them to Jolli so they're self-hosted instead. - **Internal links.** File-path links from the original repo won't resolve in Jolli; the Agent can match them to the imported Articles and rewrite them on request. Imports land **directly** in the Space - no Changeset review on the import itself. Edits you make later from the Jolli Agent chat (and AI-proposed updates from Gap Analysis) do flow through Changesets. ## Sources A Source is where a Space pulls external content from. | Kind | What it is | Auth | | ---------------------- | --------------------------------------------------- | ------------------------------------------------------ | | **GitHub App** | Private (or public) repos via the Jolli GitHub App. | Install once per org; read-only contents and metadata. | | **Public GitHub repo** | Any public repo by URL. | None. | Sources drive three things: the initial import, ongoing Gap Analysis drift detection, and optional Generate from code. See [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) for how Gap Analysis reads them. ### The two-layer model Sources live at the organization level, not per-Space. One connected Source can feed any number of Spaces. 1. **Organization Sources** - managed at **Settings → Sources**. A GitHub App installation is one row at this level. 2. **Space Sources** - each Space picks which organization Sources it consumes, under **Space Settings → Automation**. Connect once; link from any Space. ### Connecting **GitHub App.** **Settings → Sources → Connect Source → GitHub App** routes you to GitHub's install page. Pick the org and repos (All repositories or Selected). If your org admin needs to approve third-party apps, they review the read-only permissions before allowing. **Public GitHub repo.** **Settings → Sources → Connect Source → Public GitHub Repo**. Paste the URL. Once connected, link a Source to a Space under **Space Settings → Automation → Add sources**. ### Sync Connected Sources stay live. Two modes per Source: - **Webhook events** - near-real-time, default for GitHub App Sources. - **Scheduled polling** - for cases where you'd prefer suggested changes be aggregated. Tracked branch (and which repos a GitHub App can see) is configurable per Source under **Settings → Sources → Configure**. The choice between webhook-driven and scheduled sync lives per Space under **Space Settings → Automation**, because the same Source can feed multiple Spaces with different cadences. ### Source statuses - **Connected** - working normally. - **Needs Attention** - usually a lapsed permission or auth issue. Click in to see the cause. Each Source's menu has **Manage** (which Spaces use it, recent activity), **Configure** (tracked branch, sync mode), and **Disconnect** (removes from the organization; previously imported Articles stay in their Spaces). ## Generate from code If your repo has no existing docs, the Jolli Agent can write Articles directly from the codebase. You can also trigger it later by asking the Agent to generate docs for a specific part of a connected Source. Generate is slower and more variable than Import - output quality scales with how well-commented the code is and how clear module boundaries are. If you have any existing docs, even rough Markdown READMEs, Import is faster and more reliable. ## Next steps - [Editing & Organizing](https://docs.jolli.ai/jolli-spaces/editing) - the article editor and organizing a Space. - [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) - the AI agent, Changesets, and Gap Analysis. - [Jolli Sites](https://docs.jolli.ai/jolli-sites) - publish the Space at a URL. --- # Managing a Space Source: https://docs.jolli.ai/jolli-spaces/managing-a-space ## Overview Every Space has its own settings, separate from your organization's [Settings](https://docs.jolli.ai/settings). Space Settings is where you control who can work in a single Space, how automation behaves for it, where its content is stored, and whether the Space exists at all. It opens with its own left-hand menu, with a link at the top to return to the Space. ## Prerequisites - The **Admin** or **Owner** role in the Space to change most of these settings. Contributors and Viewers can open the pages but can't modify them. Deleting a Space is Owner-only. - The tabs you see depend on the type of Space and your role in it. Workflows appears only when Workflows is enabled for your organization, and Storage only when git-backed Spaces are enabled for your deployment. ## The tabs | Tab | What it covers | | --- | --- | | **General** | Name, description, visibility, and the danger zone (delete). | | **Members** | Who belongs to the Space and at what role, plus ownership transfer. | | **Automation** | Connected Sources and the auto-apply / auto-update toggles. | | **Storage** | Binds the Space to a git repository for git-backed publishing. | A **Workflows** tab also appears if [Workflows](https://docs.jolli.ai/jolli-spaces/workflows) is enabled for your organization. Not every Space exposes every tab: - **Personal Spaces** are private to you. They have no **Members** tab and no **Storage** tab, and their name, description, and visibility are read-only. - **Jolli Memory Spaces** (see [Jolli Memory](https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory)) have no **Storage** tab and no **Automation** tab (their content arrives through repository pushes rather than Source polling). In place of Storage they show a **Repos in this space** panel, covered below. ## Members The **Members** tab lists everyone who belongs to the Space, each with a role badge and the date they were added. Adding, removing, and role changes require the **Owner** or **Admin** role. ### Space roles Space roles are separate from the organization-level roles (Owner / Admin / Member) described in [Settings](https://docs.jolli.ai/settings). They apply only within a single Space. The two share the name **Admin**, but a Space Admin governs just that one Space, while an organization Admin manages the whole organization. | Role | What it can do | | --- | --- | | **Owner** | Full access within the Space. Exactly one per Space. Manages members and can transfer ownership. | | **Admin** | Manage content and members. Can assign the Contributor and Viewer roles. | | **Contributor** | Create and edit content. | | **Viewer** | Read-only access. | An organization Admin or Owner does **not** automatically get access to every Space. Their organization role lets them see Spaces set to **Public**, and nothing more - a **Private** Space they haven't been added to doesn't appear for them at all. Add them on this tab like anyone else if they need access. ### Adding members Click **Add Member**. What you see depends on your permissions: - If you can view the organization's user directory, you get a searchable list and can select several people at once. - Otherwise, you look people up one at a time by their exact email address. Pick a role for the people you're adding. An Admin can grant **Contributor** or **Viewer**; an Owner can also grant **Admin**. The **Owner** role is never assigned this way - it changes hands only through ownership transfer. ### Changing a member's role Each row has an inline role dropdown. You can change any member whose current role is one you're allowed to assign. You can't change your own role, and you can't change the Owner's role from here. ### Removing a member Use the **Remove** button on the member's row. The Owner can't be removed, and you can't remove yourself. ### Transfer ownership Only the current Space Owner can transfer ownership, and only when the Space has at least one other member. This is an invitation-based flow - ownership doesn't change until the other person accepts. 1. Click **Transfer Ownership** at the bottom of the Members tab. 2. Pick an existing member to receive the invitation and confirm. They become the new Owner and you're demoted once they accept. 3. Jolli emails the invitee an acceptance link. A Space can have only one pending ownership invitation at a time; the button is disabled (with an explanation) while one is outstanding. The pending invitation shows who it was sent to and when it expires, with **Resend** and **Cancel** actions. Removing the invited member cancels the invitation automatically. ## General The **General** tab holds the Space's basic identity and access settings. - **Space Name** and **Description** - edit each inline with the pencil icon. - **Visibility** - **Private** or **Public**. - **Default Member Role** - shown only when visibility is **Public**. ### Private vs. Public - **Private** - only the people you've added on the Members tab can access the Space. - **Public** - every member of your organization gets access automatically, at the **Default Member Role** you choose. For a Public Space, the Default Member Role can be **Contributor** or **Viewer** (Contributor by default). It applies to organization members who reach the Space through its public visibility; anyone you've added explicitly keeps the role you assigned them. Click **Save Access Settings** after changing visibility or the default role. ## Automation The **Automation** tab has two parts: the **Sources** connected to the Space (add or remove them here - see [Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces)), and the automation toggles that govern how proposed changes and Source updates are handled. - **Auto-apply change sets** - when on, routine AI-suggested Changesets apply without manual review. On a git-backed Space this becomes **Auto-merge pull requests** (which requires the GitHub App to have merge access), since git-backed Spaces publish through pull requests rather than Changesets. A new shared Space starts with it **on**, because Jolli creates it backed by a repository Jolli manages and those publish automatically. A Space you bind to your own repository starts with it off. The toggle is hidden on Spaces whose repository Jolli manages, where merging is already automatic and the choice would have no effect; it is also hidden while Jolli cannot read how the Space is backed, rather than showing a control that might not apply. - **Auto-update from sources** - when on, connected Sources are watched for changes. On a git-backed Space this reads as creating pull requests when Sources update. When **Auto-update from sources** is on, choose how updates arrive: - **Listen for GitHub events** - near-real-time, driven by webhooks. - **Check on a schedule** - polls on an interval you set (in days), at a time of day, using the timezone from your profile. See [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) for how these toggles fit into drift detection, Changesets, and review. ## Storage The **Storage** tab binds a Space to a GitHub repository so its content lives in git. This is what enables git-backed publishing - the repository becomes the source of truth, and content changes flow through it. Storage appears only on shared (non-Personal, non-Jolli Memory) Spaces, and only when git-backed Spaces are enabled for your deployment. To bind a repository: 1. Click **Connect GitHub repo** and complete the GitHub App install/authorization if you haven't already. 2. Pick a **Source** - the repositories you can use are grouped by GitHub account. A repository already bound to another Space is shown as in use and can't be selected. 3. Set the **Root path** (the folder within the repo that holds your docs) and the **Include** / **Exclude** file globs. Include defaults to Markdown and JSON files (`**/*.md`, `**/*.mdx`, `**/*.json`). Jolli tracks the repository's default branch. 4. Save. The button reads **Enable Git backing** on a first bind and **Update Git backing** afterward. **Binding a Space that already has content erases that content.** The repository becomes the source of truth, so Jolli clears what the Space held before pulling the repo in. That covers every document and folder, and also their edit history, their comments, and the Space's sync cursor. It cannot be undone. Jolli stops and asks first, naming how many documents and folders will go, and the confirm button spells out what it does - read that dialog rather than clicking through it. A Space you intend to keep is best migrated elsewhere first, or bound while it is still empty. ### Switching repositories Choosing a different repository re-binds the Space and re-clones from scratch. The clone runs in the background; while it's in progress the Space's content is temporarily unavailable. **A switch is not confirmed the way a first bind is.** The emptiness check that produces the wipe dialog applies only to a Space that isn't git-backed yet, so switching an already-git-backed Space goes ahead as soon as you save, with no dialog. The effect is still a replacement: the Space's documents are cleared and rebuilt from the new repository's files. Be sure of the repository before you save. What a switch does **not** do is throw away work in flight. Changes not yet pushed to the old repository keep syncing to that repository's pull request in the background, and Jolli says so when the switch completes. Storage also surfaces health banners when something needs your attention - for example, if the bound repository's access was revoked, if the local mirror needs to be reconnected, or if GitHub blocked the last publish because a file contained a secret. ## Repos in this space Jolli Memory Spaces show a **Repos in this space** panel where Storage would otherwise be. It lists the repositories registered to route their commit-summary pushes into this Space, and you add one here to register it. By default any repository may push into the Space, registering itself on its first push. To close that off, turn on **Restrict pushes to listed repos**: - **Off (the default)** - any repo can push, and a repo that pushes for the first time is added to the list automatically. - **On** - only the repos already listed may push. Anything else is refused, and a repo can no longer add itself. Registering a repo from this panel is the one path that still works, because this panel *is* the list. Turning it on never removes an entry, and the repos already listed keep pushing exactly as before. Changing the setting needs the **Admin** or **Owner** role for the Space. When a push is refused, the message asks you to have a space manager or owner add the repo. That is the Space **Admin** role in the table above. Someone with it can register the repo from this panel, after which pushes resume. One case to watch: a repository with no git remote cannot be identified, so it cannot be on the list. If you turn this on for the Space that Jolli Memory pushes to by default, pushes from a repo with no remote are refused too. Registering that repo is not possible while it has no remote. ## Deleting a Space Deleting a Space lives in the **Danger zone** at the bottom of the **General** tab. It's available only to the **Space Owner** - the Danger zone doesn't render for anyone else, including a Space Admin and including an organization Admin or Owner who doesn't own this Space. If you need a Space deleted and don't own it, ask its Owner or have ownership transferred to you first. Deletion is **permanent and can't be undone**. You can't delete: - Your last remaining Space. - A Personal Space. - Your organization's default Jolli Memory Space. Deletion is a two-step, guarded flow: 1. **Choose what happens to the content.** - **Move to another space** - migrate this Space's Articles into a compatible Space you pick, then remove this one. (A git-backed Space can only move into another git-backed Space, and a regular Space into another regular Space.) If there's no compatible target, this option is unavailable. - **Delete all content** - remove the Space and everything in it. 2. **Confirm by typing the Space's name.** The confirm button stays disabled until the name matches exactly. Deleting a git-backed Space carries an extra warning, since its content is tied to a repository. ## Related - [Jolli Spaces](https://docs.jolli.ai/jolli-spaces/getting-started-with-jolli-spaces) - what a Space is and what lives in it. - [Editing & Organizing](https://docs.jolli.ai/jolli-spaces/editing) - the article editor and organizing a Space. - [Jolli Sites](https://docs.jolli.ai/jolli-sites) - publish a Space at a URL. - [Settings](https://docs.jolli.ai/settings) - organization-level users and roles. --- # The Jolli Agent Source: https://docs.jolli.ai/jolli-spaces/the-jolli-agent ## Overview The **Jolli Agent** is Jolli's built-in AI agent: you give it a documentation task and it drafts the work for you. This article covers the Agent itself, the **Changesets** its edits pass through for review, and **Gap Analysis** - the Agent working on its own to catch docs that have drifted from code. Automation ties them together. For the manual writing surface - the editor, floating toolbar, auto-save, version history - see [Editing & Organizing](https://docs.jolli.ai/jolli-spaces/editing). ## Prerequisites - Edit access to the Space you point the Agent at. - **Auto mode is gated by "Allow Auto mode" in Settings.** If it is off for your organization, the Agent still drafts but waits for you to apply. - **Gap Analysis needs at least one connected Source.** Without one there is nothing for it to compare your docs against. ## Working with the Agent The AI Agent lives in the **Jolli Agent** tab. You give it a task ("write an Article about our API's auth flow"; "update the deployment guide for the new Docker setup"); it drafts content as a Changeset; you review before anything reaches the Space. **Attach image** in the chat input lets you hand the Agent a picture along with the task - a screenshot of the screen you want documented, a diagram, a design mock. The accepted formats and size limit are the same as the editor's, listed under [Editing & Organizing](https://docs.jolli.ai/jolli-spaces/editing). ### Modes | Mode | Behavior | When | | -------- | ----------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | **Plan** | The AI proposes each tool call (read file, write Article, search Source) and waits for your approval. Slow, safe. | Significant tasks; unfamiliar territory; anything you want to step through. | | **Exec** | The AI runs tools as it needs them. You see what it's doing but don't approve each step. | Routine tasks where you trust the approach but still want to review the Changeset before applying. | | **Auto** | Like Exec, plus the AI applies the resulting Changeset itself. End-to-end without you. | Truly trusted tasks. Gated by **Allow Auto mode** in [Settings](https://docs.jolli.ai/settings). | Pick from the toolbar above the chat. **Exec** is the default outside of guided workflows that use **Auto**. ### Context The Jolli Agent tracks which Article, Folder, or Space the conversation is working on. A breadcrumb under the chat header shows it (`Engineering > API Docs > Authentication API`). Context is **dynamic** by default (follows your navigation) or **snapshot** (locked to a specific target, shown with a `(fixed)` label). If context changes mid-conversation, the AI sees a small note in its next turn. Click the breadcrumb to override. ### Multiple conversations Each task gets its own conversation. The left sidebar lists every conversation, grouped by date (Today / Yesterday / Last 7 days / earlier), with a **New Chat** button at the top. Click any past conversation to resume it; the AI sees the prior turns and continues where you left off. Delete a conversation from its three-dot menu - useful for clearing out one-off explorations. ## Changesets & review A Changeset is a group of proposed edits to a Space - like a pull request for documentation. The Jolli Agent's drafts and Gap Analysis's drift fixes both land as Changesets. You review, apply, or cancel before anything reaches the Space. Direct edits in the Article editor save immediately and don't create Changesets. It's the AI-proposed edits that go through this gate. ### Reviewing Open any Changeset from its sidebar entry or from the Inbox notification that announced it. The detail view shows affected Articles on the left, a diff in the middle (additions green, deletions red), and the state / author / history at the top. Click any Article to see its proposed content; you can edit inline and your edits stay in the Changeset. Two primary actions: - **Apply Change Set** - queues the Changeset to merge onto the latest published content, then publishes it into the **Space**. It moves through `Publishing` to `Published`, and the Space's content is now current. The live **Site** is a separate build - it won't reflect the change until its next publish (see [Jolli Sites](https://docs.jolli.ai/jolli-sites)). - **Cancel Change Set** - discards the whole Changeset (`Discarded`). The Space is untouched. You can reject individual Articles within a Changeset before applying - that Article is dropped, the rest proceed. If a Changeset was drafted against content that has since changed, you may also see **Merge** or **Merge & Apply** to reconcile it, and - if a publish hits conflicts - **Force Publish**. Changesets pass through a few intermediate states (`Proposed`, `Reviewing`, `Ready`) on the way to `Published`. ### Git-backed Spaces publish through GitHub Some Spaces are bound to a git repository instead of storing content in Jolli (set up in [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space) → Storage). Those Spaces don't use Changesets at all. Their publish flow pushes a work branch (named `jolli-doc-`) and opens a **GitHub Pull Request** against the backing's source branch instead. Jolli opens and tracks those PRs for you. - Review happens on GitHub, not in the Changeset detail view. Open PRs and merged/closed ones show up in the Gap Analysis **Pull Requests** panel, split into **Open** and **Closed** tabs, each with a direct **Open on GitHub** link. - If a PR picks up merge conflicts, the panel shows a "conflicts, awaiting auto-rebase" hint - Jolli auto-rebases the branch on its next sweep, so you usually don't intervene. - The two automation toggles below still work but take on PR semantics: auto-apply reads as "auto-merge pull requests," and auto-update reads as "create pull requests when Sources update." ## Gap Analysis (automated drift) Gap Analysis is the AI scan that compares your Sources (code repos, uploads) against your Articles and flags drift. When it finds drift, it drafts fixes as a Changeset. The difference from a Jolli Agent task you start yourself: **you** start an Agent task. **The system** starts a Gap Analysis run. Drift shows up in a few common ways: - **Missing docs** - a new module, endpoint, or feature has no matching Article. - **Outdated content** - an Article describes the old behavior of something that changed. - **Incomplete coverage** - a section mentions a feature briefly but the Source now has a lot more detail. ### Triggers Configure under **Space Settings → Automation**. Turn on **Auto-update from sources**, then pick how runs fire - one or both: - **Listen for GitHub events** - near-real-time; fires when a push or merge arrives at a connected Source via webhook (requires the GitHub App). - **Check on a schedule** - polls connected Sources on an interval (every N days, at a time you set). Useful when push-driven runs would be too noisy. ### Job Activity Each Gap Analysis run (labeled **Jolli Doc Review**) shows in the Job Activity panel with trigger, status, and timestamp: - **Running** - still working. - **Changes made** - found drift; Changeset produced. - **No changes** - docs in sync. - **Failed** - click for error details. There's no manual run button. To force an immediate run, push a small change to the tracked branch or adjust the schedule to fire now. ## Automation & auto-apply By default, every AI-proposed Changeset waits for a human review. The **auto-apply** toggle removes that wait: when it's on, routine AI-suggested updates apply and publish without a manual pass. - Find it under **Space Settings → Automation** as the **Auto-apply change sets** toggle. On a git-backed Space the same control reads as **Auto-merge pull requests** (and needs the GitHub App to have merge access). - Auto-apply only applies to Changesets from Gap Analysis. Changesets from the Jolli Agent chat always require manual review - for hands-off Agent tasks, use **Auto** mode instead. - It's a shared-Space setting; the toggle is disabled on your Personal Space. - A new shared Space starts with it **on**. Jolli creates that Space backed by a repository it manages, and those publish through an automatically-merged pull request, so the control is hidden there rather than shown switched on. A Space you bind to your own GitHub repository starts with it **off**, and the toggle is yours to set. Check **Space Settings → Automation** if you're unsure which case you're in. Turn it on once you trust the pipeline - Spaces where drift detection runs frequently and changes are predictable (small wording fixes, auto-generated reference updates) are the best candidates. For where this setting lives alongside the rest of a Space's configuration, see [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space). For *scheduled* automation that generates docs on a cadence or on GitHub activity - distinct from the Agent and Gap Analysis - see [Workflows](https://docs.jolli.ai/jolli-spaces/workflows). ## Related - [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space) - Sources, automation settings, and where auto-apply lives. - [Workflows](https://docs.jolli.ai/jolli-spaces/workflows) - scheduled, hands-off doc automation. - [Jolli Sites](https://docs.jolli.ai/jolli-sites) - publish the reviewed content at a URL. --- # Workflows Source: https://docs.jolli.ai/jolli-spaces/workflows ## Overview A Workflow keeps a Space up to date for you. It watches the Sources you choose, runs a Jolli prompt against them on a trigger you set, and writes the result into a target Space - creating and updating Articles instead of you doing it by hand. Use a Workflow when documentation needs to track something that keeps changing: a codebase, another Space, or a repository's activity. ## Prerequisites - **Workflows must be enabled for your organization.** Jolli turns it on - you can't enable it yourself. If there is no **Workflows** entry in the sidebar, it isn't enabled. - Edit access to the Space a Workflow targets. - A timezone set on your profile before you use a schedule trigger, and at least one repository Source before you use the GitHub-events trigger. ## How a Workflow is built Every Workflow is defined by four parts. On the Workflows screen, each Workflow card lays these out as a labeled timeline. - **When** - the trigger that starts a run (Manual, a schedule, or GitHub activity). - **Watching** - the Sources the Workflow reads (repositories and/or Spaces). - **Then run** - the prompt that tells Jolli what to do with those Sources. - **Target** - the Space (and optional Folder) the output lands in, and how it's published. ## Where you manage Workflows There are two places to work with Workflows, and both show the same Workflow cards. - **The Workflows screen** (sidebar → Workflows) lists every Workflow you can see across your organization. Select **New workflow** to create one. - **A Space's Workflows tab** (Space Settings → Workflows) lists only the Workflows that target that Space; creating one here pins the target Space. For a Company Space, its Owners and Admins can see and pause any Workflow that targets it; for your Personal Space, only you can. You can edit any Workflow you created, plus any Workflow that targets a Space you administer. ## Creating a Workflow Select **New workflow** and fill in the form. The **target Space** and the **Workflow type** are fixed once the Workflow is created; everything else can be changed later. ### Workflow type If your organization has published its own Workflow types, a **Workflow type** picker appears so you can choose one; otherwise new Workflows use the standard freeform prompt ("None (freeform prompt)"). ### Name A short, unique label so you can recognize the Workflow in the list. ### Trigger Choose when the Workflow runs. | Trigger | When it runs | |---|---| | **Manual only** | Never runs on its own - only when you choose **Run now**. The default for a new Workflow. | | **On a schedule** | Runs on a recurring schedule at a time you set. Presets cover daily, every weekday, weekly (pick the weekdays), and monthly (by date or by weekday), plus a custom every-N-days/weeks/months option; you can also set an end date or a maximum number of runs. The schedule uses the timezone from your profile, so set that correctly first. | | **On GitHub events** | Runs when Jolli receives selected GitHub activity on a connected repository - **Pushes** and/or **Merged pull requests**. You can optionally limit it to a single `owner/repo`. This trigger requires at least one repository Source. | ### Sources Pick what the Workflow reads - **Repositories** connected to the target Space, and/or **Spaces** (including your Personal Space and Company Spaces). Only repositories connected to your chosen target Space are offered, so choose the target Space first. If some Sources are hidden because you lack access, the form notes how many you can't see. ### Prompt and starting points The **System prompt** is the instruction Jolli follows on each run - for example, "document the attached repository into this Space." Write it from scratch, or click a **Starting point** to fill in a ready-made prompt and then edit it. Starting points stay available after you begin writing your own, and **Undo** restores what was there before your last click. If the prompt uses **Prompt variables** (for example, an intended audience or a maximum number of sections), the form shows a typed field for each. Fill them in to shape the output; you can also override them per run (see below). ### Target Space and Folder - **Target space** - where the resulting Changeset lands. You can only target a Space you can edit, and it can't be changed after creation. - **Target folder** (optional) - write output into a specific Folder instead of the Space root. The Folder *can* be changed later. ### Where the output lands | Setting | After a successful run | |---|---| | **Review first** | Leaves a Changeset in the target Space for you to review before publishing. The default. | | **Auto-commit** | Publishes the run's Changeset automatically, with no review step (the **Auto-commit changes** option). | | **Pull request** | For a git-backed target Space, the run always stages output to a pull request for review - Auto-commit doesn't apply. | For how Changesets are reviewed and published, see [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent). ### Notify on completion Choose whether a finished run notifies anyone. Turn on **Send a summary when a run finishes** and pick who receives it - any combination of **Space owner**, **Workflow owner**, and **All space members**. The default is the Workflow owner; with the switch off (or no recipients selected), a finished run notifies no one. **A run that changed nothing notifies no one either**, even with the switch on and recipients picked. This is deliberate, so a Workflow on a daily schedule does not send a message every day to say there was nothing to do. It does mean silence is ambiguous: check the run history to tell "it ran and found nothing" apart from "it did not run". Notifications land in each recipient's **Inbox** as a **Workflow complete** notification, showing how many documents the run affected and whether the result was applied automatically, opened as a pull request, or is awaiting review - with links to the run and the Article(s) it produced. Each recipient is also emailed the same summary, with a **View in inbox** button that opens that exact notification. Email goes to the recipients you already picked above; there is no separate email setting to switch on. The notification's detail view also shows an **Email sent on completion** card previewing what was sent: who it was delivered to, the subject line (the Workflow name plus the number of documents updated), and the summary body. Linear and Slack are marked coming soon. ## Running a Workflow - **Run now** - every Workflow, including a Manual-only one, can be run on demand. **Run now** is the workflow card's primary button; the other actions - Duplicate, Move, and Delete - live in the card's overflow (⋯) menu. If the prompt uses variables, a dialog lets you review or override them for that run only (those values aren't saved back). A Workflow runs one at a time; if a run is already queued or in progress, Jolli tells you rather than starting a second. - **Cancel** - the primary button doubles as the stop control, so cancelling is where starting was. While a run is in flight the status line under the Workflow name reads "Run in progress…" and the button itself changes to **Running…**, both with a spinner. Choosing **Running…** asks you to confirm: **Cancel this run?** - the workflow stops where it is and publishes nothing, and you can run it again at any time. Confirm with **Cancel run**, or keep going with **Keep running**. The confirmation is there on purpose, since the button that stops a run sits exactly where the button that started it was. - **Pause / Resume** - each card has a toggle. A paused Workflow won't fire on its schedule or on GitHub events, and **Run now** is unavailable until you resume it. Pausing deletes nothing. Pausing does not stop a run that is already going, so a paused Workflow with a run in flight still shows **Running…** and can still be cancelled from it. - **When a Source disconnects** - if a repository Source is no longer connected to the target Space, Jolli pauses the Workflow and the card shows a **Reconnect source** link. Reconnect before re-enabling. - **Delete** - **Delete workflow** permanently removes the Workflow and any schedule attached to it. Past run history is preserved. Running, cancelling, pausing and deleting all need the same authority as editing: you administer the Space the Workflow targets, **or** you created the Workflow yourself. On a Company Space that means its Owners and Admins plus the person who made it; on your Personal Space, only you. Without it the card shows no run button and no pause toggle at all, rather than showing them disabled. So if you expected a **Run now** button and there is none, that is the reason. ### Duplicating or moving a Workflow From a Workflow card's overflow menu you can copy or relocate a Workflow: - **Duplicate** - creates a copy (in the same Space, or a different one you can edit). The copy starts **disabled** and keeps no run history; leave the name blank to name it after the original with "(copy)" appended, or turn on **Enable immediately** to have it start running right away. - **Move to space…** - moves the Workflow to another Space you can edit. The original is removed and its run history does not carry over. Moving needs the same authority as deleting. When you duplicate or move into a different Space, each repository Source is re-checked against the target Space; if a Source isn't connected there, Jolli tells you rather than creating a broken copy. ## Run history Each card's **History** button opens the run history. Per run you can see: - Status - **Queued**, **Running**, **Success**, **Failed**, or **Cancelled**. - How it was triggered - **Manual**, **Schedule**, or **Event**. - Duration and a short summary of what it produced. - How many documents it affected, broken out as **Created**, **Edited**, and **Deleted** (for example, "Affected 3 · Created 1 · Edited 2"), each Article linked when still active. - The publish outcome - **Applied automatically**, **Opened a pull request for review**, **Pending review**, or a **Publish conflict** / **Publish failed** state. - For a git-backed target, the pull request it opened (shown as "PR #N opened"). When a run fails, the history shows a plain-language reason - for example, that a Source could not be read, that the Sources were too large for the model's context window, or that writing to the destination failed. ## Organization defaults Organization admins can set defaults for every Workflow run under **Settings → Workflow Defaults**. These are advanced controls - the built-in defaults are sensible, and any individual Workflow can override them from its own **Advanced execution settings**. A blank field means "use the built-in default." - **Models** - which model each agent role (writer, analyzer, reducer) runs on, plus fallback models by tier. - **Agent counts & limits** - the number of writers and researchers per run, max output tokens, and the per-run timeout (values above the platform limit are capped). - **Destination article index** - whether writer agents are handed the existing target-Space Articles relevant to their task, so they update or avoid duplicating them instead of re-researching. Viewing this page needs Workflows view access; saving needs edit access. ## How Workflows relate to Changesets Unless you turn on Auto-commit, each successful run writes its output as a **Changeset** in the target Space - the same reviewable unit you get editing by hand - which you review and publish exactly as usual. For a git-backed Space, the run stages a pull request instead, and that PR is the review gate. In other words, a Workflow is an automated author feeding the review flow you already use: it proposes Article changes across your Sources, and you stay in control of what actually publishes. See [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) for that review-and-publish flow. ## Next steps - [The Jolli Agent](https://docs.jolli.ai/jolli-spaces/the-jolli-agent) - the Jolli Agent, Changesets, and Gap Analysis. - [Managing a Space](https://docs.jolli.ai/jolli-spaces/managing-a-space) - the per-Space settings a Workflow targets. - [Jolli Sites](https://docs.jolli.ai/jolli-sites) - publish the resulting content at a URL.