How the Aluy CLI is built.
The Aluy CLI is a single process that runs in your terminal — no server, no cloud in the middle of your project. It reads and edits files, runs commands and keeps the session, memory and your key on your machine. The only thing that goes out to the internet is the model call (plus any MCP connectors you turn on).
TUI Ink
The interface you type into. Themes, panels, the slash menu.
Core engine @hiperplano/aluy-cli-core
Reads and edits files, runs commands and decides the next step — the read → act → observe loop.
The permission gate single point
Every effect passes through here before it happens. Read = allow, write/run = ask, always-ask = locked.
Session & history
Transcripts, undo journal, checkpoints.
Memory
Global + per-project facts you control.
Project files
Your repo — read and edited in place.
Provider key
In the OS vault — never in plain text.
mem0
long-term memory
headroom
context headroom
ollama
local models
Model call
Through the broker by default — or your own provider, direct, with your credential.
MCP connectors
Only the ones you turn on. Databases, APIs, services you choose to reach.
One process, no daemon
Monolithic delivery: you install one binary, aluy. No background server, no hidden service.
Confined client kernel
The agent's own path-deny rules forbid it from touching ~/.aluy/ — its install, config and keys.
Sandbox & limits
OS-level confinement for shell (cgroups, egress policy) and hard ceilings on time and steps for autonomous runs.