jitera connect

connects claude code, cursor, and codex to a jitera project: documentation, source, and shared project memory over mcp.

install

npx @jitera/connect login --install

signs you in through the browser, creates a user-level api key, and configures every assistant it finds. one key covers every project your account can reach, so you run this once per machine and never again per project.

for a pilot or staging environment:

npx @jitera/connect login --env=studio-05 --install

claude code

login --install above adds the marketplace, installs the plugin and stores the key, so there is nothing to run inside claude code. a plugin installed by hand from the /plugin menu has no key and no environment; run login --install and it is configured in place.

codex

login --install configures codex too when it is installed, so there is nothing to add by hand.

cursor

npx @jitera/connect

binding a repo to a project

npx @jitera/connect init

run this once per repo, from inside the repo, and commit the three files it writes. .jitera.json records the deployment and project the repo belongs to. AGENTS.md carries the same guidance for assistants that read it natively, and CLAUDE.md imports it, because claude code reads CLAUDE.md and not AGENTS.md.

init reuses the login you already did to list your projects and asks which one this repo is. pass --project=<uuid> to skip the question: when you are signed in, that id is checked against the projects your account can see, so a typo fails instead of writing a dangling binding. pass --dry-run to see what it would write.

it refuses to run outside a git repository. instructions written above a repo are invisible to anything that reads AGENTS.md from the repo root, and a CLAUDE.md above a repo leaks into every project underneath it.

choosing which agents a repo reads

npx @jitera/connect set-agent

a project's memory is partitioned per agent. by default a bound repo reads all of them, which is right when the project is one thing and wrong when it is five: everything the other agents know arrives as noise.

set-agent lists the project's published agents with checkboxes. move with the arrow keys, press space to tick the ones this repo should read, and enter to save. the current selection starts ticked, so re-running it shows today's state rather than a blank slate. a ticks everything, n clears it.

the choice is written to .jitera.json as an agents list and committed with it, so your teammates read the same agents you do.

npx @jitera/connect set-agent --agent=<id> --agent=<id>   # skip the prompt
npx @jitera/connect set-agent --all                       # read every agent again
npx @jitera/connect set-agent --dry-run                   # show, do not write

saving nothing means every agent, which is the same as --all. memory that belongs to no agent — anything written project-wide — is always read, whatever you select, so a selection narrows the noise without hiding shared facts.

it needs the repo bound to a project first, because that is what says which agents exist. run init if it is not.

replacing your key

npx @jitera/connect new-key

use this when the key you have is read-only and you need to write, or when you just want a fresh one. it reuses the sign-in login already stored, so there is no browser round trip: it mints a new account-wide key and points your assistants at it.

new keys are read + write by default, which is what lets an assistant save memory and write specs. pass --access=read if you want a read-only one.

npx @jitera/connect new-key --access=read     # read-only instead
npx @jitera/connect new-key --name=<name>     # how it is labelled in the web app
npx @jitera/connect new-key --no-install      # print the key, change no config

restart your assistant afterwards so it picks the key up. the old key keeps working until you revoke it in the web app — creating a new one does not retire the old one.

if there is no stored sign-in it says so and points at login, which is the command that does the browser step.

what applies where

the api key is global: one per user, per machine, stored by login --install. it says who you are, not which project you are in.

.jitera.json says which project. without it a repo is unbound, and the hooks do nothing at all there: no context is gathered, no checkpoint is asked for, and no call reaches the server. a repo you have not run init in is left alone, which is why init is per repo and login is per machine.

an unbound session is not silent about it. session start tells the assistant the repo is unbound and to suggest npx @jitera/connect init, and the status line shows the same thing.

sessions also check the marker against the plugin. a teammate who has not signed in yet gets the exact login command for the right environment. a teammate pointed at a different environment gets a warning instead of quietly reading the wrong project.

the proxy and the hooks send the project it names as an X-Jitera-Project header and as a com.jitera.boost query parameter (the gateway strips unknown headers), so several repos on one machine can talk to different projects through a single key. older deployments bind the key itself to one project; there the marker still decides whether the hooks run, and makes a mismatch visible.

the configure command without --env uses the environment recorded in .jitera.json, so a teammate who pulls a pilot or staging repo does not have to re-pass --env. an explicit --env still wins.

when no deployment is selected, interactive setup, login and init look for STUDIO_URL in the Jitera CLI's ~/.jitera/clirc. a non-production address is shown for confirmation before any request is made to it. answering yes saves it in ~/.config/jitera-connect/endpoint.json for later runs; enter or no keeps the production default. dry runs never save it, and non-interactive runs never adopt an unconfirmed address. explicit flags and JITERA_STUDIO_URL take precedence over saved settings.

a self-hosted deployment has no name to pass. give login its address instead, and init and new-key read the deployment from the saved sign-in:

npx @jitera/connect login --endpoint=https://jitera.example.com --install

init records that address in .jitera.json, so the repo carries the deployment for teammates and for the proxy. --endpoint is accepted anywhere --env is.

seeing your keys

in the jitera app your own keys live under your avatar, then account, then api keys. you can create and revoke them from there. project keys sit in the project's settings, agent keys under the agent, and organisation keys under settings, then organisation.

the api key

login creates a user-level key when the deployment supports it. older deployments issue project-scoped keys, so login falls back to asking which project and tells you when that happens.

login --install stores the key for you, so there is nothing to export:

• claude code: your os keychain
• cursor and codex: their own config in your home directory, outside any repo

it also keeps a private session at ~/.config/jitera-connect/session.json, mode 0600, so init can list your projects without another trip through the browser.

installing without login leaves cursor and codex reading JITERA_API_KEY from the environment:

export JITERA_API_KEY=<your api key>

status line

login --install also puts the connection in claude code's status line:

● jitera · studio-05 · recall 1.2k/0.4s

green means the session is configured, hollow means not connected, and yellow means a failed recall or a repo asking for a different environment. it reads state the hooks already wrote, so it never touches the network, and it resolves the installed plugin version when it runs, so an update does not orphan it.

claude code has one status line slot. if something else already owns it, login leaves it alone and says so. remove yours and run login again, or point statusLine at the plugin's dist/bin/statusline.js yourself.

pilot and staging environments

claude code:

npx @jitera/connect login --env=studio-05 --install

that installs the plugin already pointed at the pilot. to move a plugin that is already installed to another environment:

/plugin configure jitera-connect

cursor and codex:

npx @jitera/connect --env=studio-05
npx @jitera/connect --env=studio-stage

other flags

npx @jitera/connect --print         print the resolved endpoints and exit
npx @jitera/connect --dry-run       report what would change, write nothing
npx @jitera/connect --uninstall     remove the jitera server
npx @jitera/connect --skip-skills   write mcp config only
npx @jitera/connect --endpoint=<url>  name a self-hosted deployment