sthayi

AI memory you own.

A sovereign, local-first memory / skills / MCP-registry plane — so supported AI clients on your machine can read and write one shared local memory that you own.

sthayi (Sanskrit): permanent, enduring. The sthāyī bhāva is the enduring emotion beneath transient states; the sthāyī in Hindustani music is the refrain a raga always returns to. Pronounced "STAY-ee."

Your memory today can be scattered across Claude, ChatGPT, Gemini, Cursor, and CLI agents — multiple apps, multiple fragments, none of them yours. Sthayi is not another silo and not a replacement: it coexists with each app's built-in memory — in addition, not instead — as one shared local memory exposed to supported clients over MCP. There is no hosted Sthayi service and no Sthayi account — only the local MCP server running on your machine. Theirs stay theirs. This one is yours.

Quickstart

Prerequisite: Node.js 22 or 24

Sthayi v0.1.3 supports Node.js 22 and 24, with Node 24 LTS recommended, and requires npm. Check both before installing:

node --version
npm --version

node --version must begin with v22. or v24.. If Node is missing or reports any other major version—including Node 25—install Node 24 LTS from the official Node.js download page using the normal/default location offered for your operating system. npm is included with the standard Node.js distribution. Reopen your terminal afterward, then run both checks again. Sthayi refuses an unsupported Node major before loading its native SQLite dependency and explains this repair.

Node.js does not need to be installed inside Sthayi's prefix. Installing Node.js is a separate prerequisite and may require administrator approval, depending on the operating system and install method. Once Node.js and npm are available, the Sthayi installation below stays in user space and needs neither sudo nor administrator rights.

Install and initialize

Sthayi v0 uses a better-sqlite3-backed local store. The user-space command below first refuses any Node major other than 22 or 24, then requests the npm latest tag explicitly and makes npm enforce the package's engine declaration. Those two npm qualifiers prevent an unsupported Node runtime from silently selecting an older compatible release. Do not substitute npx sthayi init.

Contributing from a source checkout instead? Use the Development workflow.

# macOS / Linux — bash or zsh
node -e "const m=Number(process.versions.node.split('.')[0]);if(m===22||m===24){}else{console.error('Sthayi requires Node.js 22 or 24 (24 LTS recommended). Detected '+process.version+'. Install Node.js 24 LTS: https://nodejs.org/en/download');process.exit(1)}" && npm install -g --prefix "$HOME/.local" --engine-strict sthayi@latest && "$HOME/.local/bin/sthayi" init

One line: install once somewhere durable, then detect your AI clients and wire them in one keystroke.

After the wizard completes, verify the default installation and state directory:

"$HOME/.local/bin/sthayi" doctor

This invokes the package from the durable install prefix; doctor reports the configured state directory, including a custom absolute STHAYI_HOME when one is set.

Why the npm flags, and what they do not touch. --prefix and --engine-strict are per-invocation flags: they tell this one npm install where to put the package and to refuse an unsupported engine, while changing nothing in your npm configuration. No ~/.npmrc is written, npm config get prefix reads exactly what it read before, and every other npm command you run is unaffected. The install lands under your home directory, so installing Sthayi itself needs no admin rights once Node.js and npm are available — including on machines where npm's default global prefix is root-owned and a plain npm install -g sthayi fails with EACCES.

Where things land:

The package and the memory are two separate directories, and they are removed by two separate acts: npm uninstall takes the first, and the second is yours alone (see Upgrade & uninstall).

No account. No required API key for ordinary core operation. No telemetry. No administrator rights for the Sthayi user-space install once Node.js and npm are available. Wiring, however, edits each AI client's own config file (after saving a *.sthayi-bak-* backup beside it) — so removing Sthayi starts with sthayi unwire, which restores or surgically updates those configs as described below. Removal of the state directory itself is a separate decision, and one Sthayi leaves to you; see “Upgrade & uninstall” below.

npx sthayi init is refused, and this is why. npx runs the CLI out of npm's download cache, which is pruned without warning. init writes launchers that pin the exact CLI they were written from, so a launcher pinned into that cache is wiring that breaks the next time npm cleans up. Sthayi refuses to write one and tells you where to install instead — onboarding is a durable install first, then sthayi init. (Commands that write no launcher — npx sthayi@latest status, npx sthayi@latest doctor, npx sthayi@latest search — do run from the cache. search is not read-only, though: every search journals a memory_retrieve, bumps recency, and strengthens the association graph.)

What “durable” means: anywhere you keep, not anywhere privileged. Only three locations are ephemeral — an _npx/_cacache path, your system temp directory, and your npm cache. Everything else is pinned exactly where it stands. No Sthayi installation route below needs admin rights or sudo once Node.js and npm are available — where a route cannot proceed it fails outright, and the answer is a different route, never elevation. Each is one copy-pasteable bash/zsh line that runs as typed:

# 1. THE HEADLINE ROUTE — a prefix inside your own home. This is the durable user-space route.
node -e "const m=Number(process.versions.node.split('.')[0]);if(m===22||m===24){}else{console.error('Sthayi requires Node.js 22 or 24 (24 LTS recommended). Detected '+process.version+'. Install Node.js 24 LTS: https://nodejs.org/en/download');process.exit(1)}" && npm install -g --prefix "$HOME/.local" --engine-strict sthayi@latest && "$HOME/.local/bin/sthayi" init

# 2. npm's default global prefix. Available ONLY when your account can already write that prefix
#    — version managers normally put it inside your home. A default single-user Homebrew install
#    normally makes its prefix writable by the installing user. Check: npm config get prefix.
#    If your account cannot write that prefix, use route 1; never add sudo. Its bin is usually on PATH.
node -e "const m=Number(process.versions.node.split('.')[0]);if(m===22||m===24){}else{console.error('Sthayi requires Node.js 22 or 24 (24 LTS recommended). Detected '+process.version+'. Install Node.js 24 LTS: https://nodejs.org/en/download');process.exit(1)}" && npm install -g --engine-strict sthayi@latest && sthayi init

# 3. A plain local install is durable too. Its binary lives in node_modules/.bin.
mkdir ~/sthayi && cd ~/sthayi && node -e "const m=Number(process.versions.node.split('.')[0]);if(m===22||m===24){}else{console.error('Sthayi requires Node.js 22 or 24 (24 LTS recommended). Detected '+process.version+'. Install Node.js 24 LTS: https://nodejs.org/en/download');process.exit(1)}" && npm i --engine-strict sthayi@latest && ./node_modules/.bin/sthayi init

Route 1 is the headline because a normal per-user home is the most reliable writable location. Route 2 is the shorter line, and it is worth using when you know the prefix is writable by your account — but it is not universally admin-free.

PATH is optional, and irrelevant to the MCP integration. Your AI clients invoke ~/.sthayi/bin/sthayi-mcp by absolute path, so wiring works whether or not anything is on your PATH. PATH only decides whether you can type sthayi in a terminal. init also writes ~/.sthayi/bin/sthayi, a launcher pinned to the same install, so the sthayi <command> forms below work by full path (~/.sthayi/bin/sthayi status) — or on PATH, once. Both launchers live in your state directory, so where you have set $STHAYI_HOME they are $STHAYI_HOME/bin/… instead; sthayi doctor reports the home in use:

export PATH="$HOME/.sthayi/bin:$PATH"    # add this line to your shell profile

Windows: the same architecture and the same user-space prefix. The per-shell forms below are host-validated (evidence recorded at v0.1.0) with the checksum-verified packed tarball under a standard (non-administrator) account. That packed-tarball evidence does not itself cover delivery from the npm registry; the npm package-name fetch smoke is a separate pre-announcement release gate. Sthayi never modifies PATH itself, on any platform.