msa

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.

Direction

• 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 a package.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.

Getting started

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/msa

Or 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/msa

Releases ship msa-darwin-arm64.tar.gz, msa-darwin-x64.tar.gz, msa-linux-x64.tar.gz, msa-linux-arm64.tar.gz, msa-windows-x64.zip, msa-windows-arm64.zip, and SHA256SUMS. 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.sh

The checkout requires Node.js 22.19 or newer. 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.

Values that identify the client to external services (the pi/<version> User-Agent, pi.dev endpoints, the Codex login identifier) intentionally keep the pi name, because those services know the client by it.

Packages

This monorepo contains the msa CLI and its supporting libraries.

Package	Description
@msa/chord	Typed host runtime for hot-reloadable plugins, contracts, replicated state, and RPC over JSON links
@msa/telemetry	Vendor-neutral telemetry contracts, reference adapter, conformance tests, and typed schemas
@msa/ai	Unified multi-provider LLM API (OpenAI, Anthropic, OpenRouter, etc.)
@msa/durable	Durable conversation, task, and document runtime
@msa/agent-core	Agent runtime with tool calling and state management
@msa/coding-agent	Interactive coding agent CLI
@msa/tui	Terminal UI library with differential rendering
@msa/web	Cloudflare Worker that records CI job and step timings

Deployments

• CI telemetry receiver: https://msa-ci-telemetry.masseater.workers.dev (deployed by the deploy job of .github/workflows/verify.yml on main)

Permissions & Containerization

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 msa and provider auth on the host while routing built-in tools and ! commands into a local Linux micro-VM.
• Plain Docker: run the whole msa process in a local container for simple isolation.
• OpenShell: run the whole msa process in a policy-controlled sandbox.

Development

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 ~/.local

Release binaries

vp run build-binaries builds msa for every release platform into .artifacts/binaries (msa-<platform>.tar.gz, msa-<platform>.zip, and SHA256SUMS) and runs msa --version from the host platform's archive; with MSA_LOCAL_LLM_TESTS=1, which CI sets, it also has that binary decide a task review through node-llama-cpp. Pushing a v* tag runs .github/workflows/release.yml, which builds them in CI, smoke-tests the result, and publishes a GitHub Release. vp run render-homebrew-formula renders Formula/msa.rb from SHA256SUMS into .artifacts/homebrew; the workflow pushes it to masseater/homebrew-tap once the release is published.

License

MIT. msa started as a fork of pi, which this project gratefully builds on.