Install and activate

macOS and Linux, on Apple silicon or x86-64:

Two binaries are installed: chi, the CLI, and chi-mcp, the server your coding agent talks to. They go in /usr/local/bin when that directory is writable and ~/.local/bin otherwise. The installer never uses sudo — a script piped from the network should not escalate, and a tool in your own bin directory works just as well.

Three environment variables change what it does:

curl | sh deserves the suspicion it gets, so here is exactly what the script does and why it is verifiable.

1. 1
   It asks which build matches this machine

   Over TLS, from a host we control. The reply names the archive and states its SHA-256.
2. 2
   It downloads the archive from object storage

   A different host. This is the part of the design that does the work.
3. 3
   It verifies the hash before anything lands on disk

   The hash came from one host and the bytes from another. Someone who could tamper with the storage bucket still cannot make the hash match, and someone who could tamper with the API response cannot serve the bytes. A single host serving both would collapse that argument.
4. 4
   It installs atomically

   Each binary is written under a temporary name and renamed into place, so an interrupted install cannot leave a truncated binary where a working one used to be.

The script is POSIX sh, a little over three hundred lines, and served at /install.sh — read it before you run it if you would rather. Nothing in it is minified or fetched at runtime.

If its directory is not on your PATH, the installer adds it to every shell startup file you already have (~/.zshrc, ~/.bashrc, ~/.bash_profile, fish's config.fish) and prints the line for the shell you are in. Open a new terminal, or run that line, then check:

It never creates a startup file you don't have, and never adds the line twice. Both binaries must be reachable: chi-mcp is launched by your coding agent rather than by you, and a registration that names a path the agent cannot resolve fails at the agent's next session rather than now. chi doctor catches that.

Archis needs a free account, and each machine you use is activated once. Signing in opens your browser; GitHub or Google creates the account if you don't have one, no card is asked for, and the browser hands the activation back to the waiting CLI.

On a machine with no browser — an SSH session, a container, a devcontainer — use chi auth login --no-browser. It prints a URL and a code to open on a machine that does have one.

chi auth status says what the licence grants and until when. It works offline: the licence is a signed document the CLI verifies locally, and it keeps working for up to four days without a connection. See Privacy and licensing.

One command checks the installation and says what is wrong with it. It changes nothing, which is what makes it safe to run when confused — the only time anybody runs it.

Three narrower reports answer the questions that come up most:

chi doctor --json exits non-zero when something needs attention, so it works as a provisioning gate.

chi update replaces the binary you are running. It verifies the download before it becomes that binary, swaps it atomically, and puts the old one back if the new one cannot even print its own version. Credentials, consent settings and local graphs are untouched.

chi update --channel beta follows the beta channel instead. The changelog lists what each release changed.

chi eject is the exact inverse of chi init. It removes the index, the settings Archis wrote, and every block it added to a file it does not own — and nothing else. It prints the full plan first and asks before acting.

There are three scopes, and each one is a different decision:

--keep-sessions keeps each repository's working history, which is the one thing chi index cannot rebuild. --dry-run prints the plan and stops, and a run with no terminal to ask at has to say --yes itself.

None of this needs a valid licence. Whatever Archis puts on a machine comes back off a machine whose licence has lapsed — a lapsed plan is the most likely moment to want exactly that.

One command for a machine that is finished with Archis:

The order is the whole design, and it is why this is one command rather than a note telling you to delete the binary. chi is the only thing that knows where Archis put anything, so everything it can remove is removed while it is still on the machine, and the binary goes last:

1. 1
   Every repository it indexed

   chi eject --all --yes. A repository that fails — a read-only volume, a settings file somebody locked — is reported and does not stop the rest.
2. 2
   The machine-wide setup

   chi eject --machine --yes: hooks, briefing, skill, permission entry, every agent registration.
3. 3
   The sign-in

   chi auth logout clears the lease and the stored token — the keychain entry on macOS — and releases this device's activation back to your account.
4. 4
   What the installer changed

   The *.chi-backup copies Archis made before editing any of your files, and the line the installer appended to your shell startup file — its own marker comment and the line under it, and nothing else in the file.
5. 5
   The binaries

   chi and chi-mcp, from wherever they were installed. No sudo: a directory this cannot write to is reported with the command that would.

Every step says what it did per path, and names the command that finishes anything it could not — a binary in a directory you do not own, a registration in a harness that is no longer on the machine. None of it needs a valid licence, which matters most on the machine whose plan has lapsed.

What happens to the rest is up to the flags:

Without --purge the state directory stays and the script prints its path and the one command that removes it. That is deliberate: it holds the keys your indexes were encrypted with, so deleting it makes any .chi directory this run did not remove unreadable rather than merely stale.

If the binary is already gone — deleted by hand, or never installed by the installer — the uninstaller script does what it can from outside, and hands the work to chi uninstall whenever it finds a binary that has it: