momo-code has two evolution loops, and one of them edits your shell rc

curl piped to bash, then a PATH line in your shell rc

The recommended install is one line:

curl -fsSL https://momozi.cc/install | bash

The script's four steps are described rather than shown: it clones the repository into ~/.momo/lib/momo-code, runs npm install and npm run build for something like 30 to 60 seconds, drops a wrapper at ~/.momo/bin/momo, and appends ~/.momo/bin to PATH in either ~/.zshrc or ~/.bashrc. Because the last step edits a shell startup file, a new terminal is required, or you have to source the file yourself, and a shell that was already open will report:

command not found: momo

which the troubleshooting section of INSTALL.md addresses. The manual path avoids all of that at the cost of doing the same steps yourself, and it clones into a monorepo checkout whose package lives in packages/opencode rather than at the root.

Uninstall greps for a marker comment the install step never mentions

Removal is two shapes of command:

rm -rf ~/.momo
sed -i.bak '/# momo Code CLI/,+1d' ~/.zshrc    # zsh
sed -i.bak '/# momo Code CLI/,+1d' ~/.bashrc   # bash

The sed pattern is anchored on a marker comment and deletes that line plus the one after it, which is the shape of a two-line block a script wrote deliberately. The install description, however, says only that the PATH directory is appended to the rc file. If the marker is absent, the pattern matches nothing and the PATH line survives, which is the failure mode worth checking before you assume a machine is clean.

Two smaller details: the -i.bak suffix leaves a copy of your shell rc next to the original, which is polite and also means your dotfiles directory gains a file each time you run it, and deleting ~/.momo removes the configuration, the session history and the learned tactics together, so there is no partial removal if you want to keep the session log.

Every root script is a cd into packages/opencode

The root package.json is a thin proxy. Each script changes directory and delegates:

"build": "cd packages/opencode && npm run build"

with the same pattern for dev, typecheck, lint and test. The package is private, so nothing is published from the root, and its name is momocode rather than the product name.

The versions disagree in a way that will trip up anyone automating this. The root package is at 0.1.1, the only GitHub release is v1.0.0 from 2026-06-16, and the documented check after install is momo --version printing 1.0.0. Distribution has its own gap: the npm package is announced as coming in v1.1, and the note tells you to use the quick install for v1.0. So the version a package manager would see, the version in the repository, and the version the installer reports are three different numbers.

The repository is not archived and its last push was 2026-09-16, with 923 stars, 5 forks and no open issues, and the project is described as open source and auditable with your code staying on your machine.

One loop injects tactics, the other moves weights

The dual-speed claim is specific about the timescale of each half. The fast loop, /evolve, works in seconds: it injects tactics into the prompt through what is called the KEP protocol, choosing among tactics distilled from past successes by Thompson sampling rather than by fixed priority. Its flags expose the strategy surface directly, with modes for explore, harden and convention-only, plus --list to show the learned set, --inject to apply tactics to the current task, and --solidify to apply a verdict and update the statistics.

The slow loop, /fine-tune, works in hours and is a real training run: Monte Carlo Graph Search combined with LoRA. Its subcommands separate diagnosis from execution, so /fine-tune shows a proposal, /fine-tune run executes it, /fine-tune run --dry-run previews without executing, and /fine-tune status reports progress.

Between them sits /refine, which reviews session trajectories and proposes small evidence-based improvements, described as tactics or prompt patches. Those take effect only after human approval, which is the one place in the feature list where a self-modifying change is gated on a person.

Long-horizon work comes in four shapes

Beyond the two loops, the commands divide by how long a task is allowed to run. Recursive subagents, /agent, decompose a task RLM style into a plan, parallel child processes and a synthesis step, with rails on depth and budget. The graph engine, /graph, treats a long-horizon task as a resumable directed acyclic graph of subagents, with an LLM-planned dependency graph, parallel execution, retries, and the ability to hang simulation nodes off it. Persistent work is covered by /goal for goals injected into every session, /heartbeat for timed tasks, and /daemon for a loop that keeps working across hours.

The simulation agent, /sim, is the odd one out: it drives a persistent Genesis physics world where the agent writes Python into a long-lived namespace and loads skills as code from ~/.momo/sim/skills/. Voice input, /voice, runs microphone capture through sounddevice into an OpenAI-compatible speech-to-text service such as Whisper or Groq and from there into a coding session.

Model selection is either an explicit provider and model or one of three zero-config tiers: ultra for complex work with large context, standard for daily coding, and lite for quick tasks at low latency. More than 25 providers are named, and a custom OpenAI-compatible endpoint can be plugged in through MOMO_CUSTOM_* variables, while /chat is restricted to the OpenAI-compatible protocol.

The learned state is two files you can read

On first run the tool creates ~/.momo/, and the layout is small enough to inspect:

~/.momo/
├── momo.jsonc          # Config
├── sessions/           # History
├── experience/         # Learned tactics (auto-created)
│   ├── tactics.json
│   └── ledger.jsonl
└── ...

A tactics file holding the current set and an append-only ledger beside it is a better shape than an opaque model artifact, because the two together are what /evolve --solidify updates and what /evolve --list prints. The same directory holds configuration in JSON with comments and the session history, and deleting the directory removes all three at once.

Keys are configured through the environment. A generic MOMO_API_KEY works with any provider, and provider-specific variables such as MOMO_ANTHROPIC_API_KEY and MOMO_OPENAI_API_KEY are supported alongside it. The command line itself is deliberately small: a model or provider flag, help and version, with the coding session launched by passing a prompt string.

There is also a migration path from Claude Code, which inherits a .claude directory with its configuration, MCP servers and prompts, so an existing setup carries over rather than being rebuilt.

MIT in package.json, use restrictions beside the LICENSE file

The licensing arrangement needs reading rather than skimming. package.json declares MIT, a LICENSE file sits at the root, and the repository's own license metadata field is left unset, which is why the license shows as unasserted on the index page. Next to the license are three files that change the reading: NOTICE, SECURITY.md and USE_RESTRICTIONS.md, plus USER_GUIDE.md and INSTALL.md. A use-restrictions document sitting beside an MIT declaration is a contradiction worth resolving with the project before you redistribute or embed the tool, since the MIT text grants permission and a restrictions file can narrow it.

The tree has a few other things worth noting. There is an install script at the root, which is what the curl pipe fetches, and there are two script directories, script/ and scripts/, which differ by one letter and are a standing invitation for confusion. Documentation is split between English and Chinese READMEs with a docs directory, and there are agent instruction files at the root in both AGENTS.md and CLAUDE.md.

The stated platform requirement is macOS or Linux, with Windows through WSL, plus Node.js 20 or newer, git and curl. The only release is v1.0.0 from June 2026, so the fast loops described above are new relative to the only tagged build.

Editorial conclusion

momo-code is interesting if you want to watch an agent accumulate tactics and want the option of a real training run later, and uninteresting if you want a predictable coding tool, because both loops change behaviour over time and the faster one changes it without asking. Three checks before you install it. Where the code comes from: the quick install fetches a script from a project domain and pipes it into bash, then clones a repository and builds it, so the trust chain is the site, the repository and your npm dependencies. What it writes to your shell: the installer appends a PATH line and the uninstall depends on a marker comment that grep-based removal needs but the install description does not mention. And what the license actually permits: package.json says MIT while a USE_RESTRICTIONS.md sits beside the LICENSE file and the index metadata names no license at all.

Frequently asked questions

Official sources

1. Issues
2. momozi1996/momo-code on GitHub
3. Project website
4. README
5. Releases