msa is masseater's agent harness: an opinionated coding agent built around how masseater works. It started as a fork of pi, but it is now a completely separate project with its own name, package scope, config directory, and direction. pi is not msa's upstream.
- Not minimal. pi keeps its core small and leaves features to extensions. msa does the opposite: a feature that proves useful goes into the core, on by default, instead of living in an extension you have to find and install.
/goal, for example, is built in. - masseater style. Defaults, commands, and workflows follow masseater's habits. Claude Code is the reference for command names and behavior, so moving between the two needs no relearning.
- pi extensions keep working. Extensions written for pi load as they are:
@earendil-works/pi-*imports resolve to the bundled packages, and apackage.json"pi"manifest is still read. When an extension turns out to be worth having for everyone, msa absorbs it into the core. - pi is not an upstream. msa does not follow, track, or merge pi. When a pi feature is judged worth having, msa takes it in feature by feature and implements it in msa's own way. pi code is never copied in as is.
Planned work lives in the issues.
You can still customize msa with extensions, skills, prompt templates, and themes, and bundle them as msa packages to share via npm or git.
Use msa interactively, automate it in print or JSON mode, control it over RPC, or build apps with the msa TypeScript SDK.
msa is not published to npm, and the pi.dev installer installs pi, so install msa with Homebrew, from a release, or run it from a checkout:
brew install masseater/tap/msaOr download and extract a release archive directly:
curl -fsSLO https://github.com/masseater/msa/releases/latest/download/msa-darwin-arm64.tar.gz
tar -xzf msa-darwin-arm64.tar.gz
./msa/msaArchives are published for macOS, Linux and Windows on x64 and arm64. On Windows, unzip the archive and run msa.exe.
To run from a checkout instead:
git clone https://github.com/masseater/msa.git
cd msa
vp install
./scripts/msa-dev.shThe checkout runs on the Node.js version in .node-version; vp and version managers that read the file pick it up, and the tests fail on any other version. State lives in ~/.msa/agent, next to settings.json, auth.json, and sessions.
Run /login inside msa to connect a subscription or API key, then give msa a task.
Install the treg CLI and sign in from msa with /login treg (or treg login, or set TREG_TOKEN), and msa gets web_search and web_fetch tools, on by default. treg tries free TinyFish first and falls back to other vendors, and uses keys you registered in treg (Exa, for example) before its own.
- CI telemetry receiver: https://msa-ci-telemetry.masseater.workers.dev
msa does not include a built-in permission system for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it.
If you need stronger boundaries, containerize or sandbox msa. See apps/coding-agent/docs/containerization.md for three patterns:
- Gondolin extension: keep
msaand provider auth on the host while routing built-in tools and!commands into a local Linux micro-VM. - Plain Docker: run the whole
msaprocess in a local container for simple isolation. - OpenShell: run the whole
msaprocess in a policy-controlled sandbox.
vp install # Install all dependencies
vp run build # Refresh model data, then build all packages
vp run verify # Lint, type check, tests, model data check
./test.sh # Run tests (skips LLM-dependent tests without API keys)
./scripts/msa-dev.sh # Run msa from sources (can be run from any directory)
vp run install-local # Build and install the host binary to ~/.localMIT. msa started as a fork of pi, which this project gratefully builds on.