indra CLI

The indra CLI

One small binary: graph memory and an agent web console. Install and build it.

One small CLI for AI agent harnesses: a graph memory your agents (and you) can read and write, and a web console to view, monitor and run the agents themselves. One Rust binary for Linux, macOS and Windows, with no runtime, database, server or account to set up.

It is named for Indra's net (Indrajala): an endless net with a jewel at every knot, each jewel reflecting all the others. That is the memory model - everything links to everything - and Indra, king of the devas, is a fitting name for the thing that commands the agents.

The security harness is the default profile, any Claude Code project is picked up automatically, and any other harness is a few lines of TOML.

Install

One line (picks the build for your machine, checks its SHA-256, puts it on your PATH):

curl -fsSL https://raw.githubusercontent.com/dmdhrumilmistry/indra/main/install.sh | sh   # Linux, macOS
irm https://raw.githubusercontent.com/dmdhrumilmistry/indra/main/install.ps1 | iex       # Windows (PowerShell)

Then indra serve --open. The installers also set up Tab completion for your shell. They take INDRA_VERSION=indra-v0.2.0 for a specific release, INDRA_INSTALL_DIR for another folder (default ~/.local/bin, or %LOCALAPPDATA%\Programs\indra), INDRA_AUTO_UPDATE=1 to turn on automatic updates, and INDRA_NO_COMPLETIONS=1 to skip completion.

Updates. indra update installs the newest release (--check only asks; --version picks one), checking its SHA-256. Once a day, when you use indra in a terminal, it looks for a new release in the background and the next command tells you, at most once a day. To have it install new releases by itself:

indra update --auto on    # off: back to just telling you

The check runs at most once a day, in a detached indra update --background, never slows a command down, and also runs every few hours inside a long-running indra serve (the console's version shows when a new one is out; an automatic update takes effect when indra serve restarts). INDRA_NO_UPDATE_CHECK=1 turns checks off entirely, and they are off under CI and for the remote side of a node. What it knows is in <data dir>/update.json.

Tab completion. The installers set it up; by hand:

indra completions --install          # your shell (bash, zsh, fish, PowerShell)
indra completions zsh > _indra       # or print the script for a shell and place it yourself
indra completions --uninstall        # undo

For bash, zsh and PowerShell, --install writes the script under indra's data directory and one marked block (# >>> indra completions >>>) in ~/.bashrc, ~/.zshrc or $PROFILE that loads it; fish gets ~/.config/fish/completions/indra.fish. indra update refreshes the script, so new commands complete after an update.

Prebuilt, by hand: download indra-<target> from an indra-v* release (each file has a .sha256, and SHA256SUMS lists them all), rename it to indra (indra.exe on Windows) and put it on your PATH. Builds exist for Linux (x86_64 and arm64, static, any distro), macOS (Apple silicon and Intel) and Windows (x86_64).

One binary for every role. The console (indra serve) and a machine that runs agents for it (indra node connect, or plain SSH) are the same file, like gh or docker: one download, one version to keep in step, no mismatched pieces.

From source (any platform with Rust 1.89+):

cargo install --locked --git https://github.com/dmdhrumilmistry/indra indra
# or, from a clone:
cargo install --locked --path tools/indra

Review tooling

The deterministic parts of a review are subcommands of the same binary, so the indra plugin's skills need no interpreter on any platform:

Maintainer commands: indra dev site builds the website (site/ plus the docs pages listed in site/pages.toml, rendered from the Markdown, with a broken-link check), and `indra dev dashes [--fix]` finds em and en dashes.

The same, from the console

Every one of these is also in indra serve, calling the same code, so the command line and the console always agree:

• A run's page (Runs, then a run) has Next steps when the run has a verified.jsonl or a PR review payload: Record into memory (with a preview of the commands), Publish (pick the destination, lowest severity and whether to include needs-runtime findings; download or copy the plan for the sh-publish skill), and Post to GitHub for a PR review (a dry run first; the repository and PR number come from the run's run.json and can be changed).
• Tools shows the review cache (with prune and clear, per repository or all), the local metrics (totals, per model, per run; drop old records or delete them), the skills (whether the skills/ mirror is current, sync it, install the skills for an agent, for you or in a target), and the maintainer chores (build the site into _site, look for dashes).

Writes are refused when the console is read-only; previews and dry runs are not. Posting runs gh as you, on the machine running indra serve, after you confirm.

Development

cd tools/indra
cargo test            # unit tests, API security tests, end-to-end tests of `indra mem`,
                      # and orchestration over SSH (with a stand-in ssh client)
cargo clippy --all-targets -- -D warnings
cargo fmt --check
cargo run -- serve --target /path/to/project

src/mem/ is the memory engine, src/deck/ the console, ui/ its front end (plain JavaScript, embedded at build time), src/review.rs, src/publish.rs and src/mem/record.rs the review tooling, src/skills.rs and src/site.rs the maintainer tools. The tests start stand-in agents written in Python, so cargo test needs python3 on Unix; nothing that ships does. Dependencies: axum, tokio, clap, serde, serde_json, toml, getrandom (and libc on Unix).

MIT licensed, like the rest of this repository.