Published release
MOMM 1.17.3
An update no longer stops because a harness command is slow to start: the installer finds harness commands on PATH instead of timing them, and the updater gives the reason when a harness cannot be verified. Signed lifecycle drills passed on six hosted Windows/macOS/Linux Node 18/24 cells, upgrading from 1.17.2 and 1.17.1.
Published 2026-10-06 · Tag momm-1.17.3
Original source record ↗MOMM 1.17.3 — release notes
Released 6 October 2026. The signed tag momm-1.17.3 names commit 507e5f778110755be91eebc03ef4309538414857, the exact sealed candidate tree squash-merged from pull request 51. Do not install an unsigned branch as a signed release.
The immutable signed tag retains the pre-publication notes (publication pending) and the version-notes history entry that were sealed before release. This post-release document and the live release page are the publication record; the signed payload is not retagged or resealed merely to change its historical notes.
Release evidence: exact-main CI, 15/15, signed checkpoint, six hosted lifecycle cells, 13/13 steps each, and stable signing and update smoke. Every lifecycle cell exercised recovery from interrupted upgrades from both 1.17.2 and 1.17.1. Fresh-clone verification validated the Git signature, Rekor entry, expected certificate claims and sealed payload; an intentionally wrong signing identity was refused.
1.17.3 is a patch for updating MOMM. Nothing changes in how a review runs. One writer, read-only reviewers, account logins only and automatic updates off: none of that changes.
What was wrong
- On 6 October 2026 an update from 1.17.1 to 1.17.2 on the maintainer's Windows machine stopped twice with
Harness replay did not verify momm for gemini, and its automatic recovery reportedAutomatic recovery incomplete. - After the checkout the updater runs the installer for each harness in the install receipt. The installer decided whether a harness command exists by running
<command> --versionwith a five-second limit, and treated any failure, a timeout included, as "not installed". - The Gemini CLI was installed and on PATH, but took between 5.5 and 7.7 seconds to print its version in four timed runs, while other sessions were busy on the machine. So the installer reported
gemini command not installed, which was false, the updater saw no verified link for a harness its receipt lists, and refused. The recovery replays the same harnesses and stopped the same way. - The retained rollback command, run by hand, worked whenever the command happened to answer in time. The same update had worked two days earlier, when it did.
Anyone whose receipt lists a harness whose command takes more than five seconds to print its version could be stopped this way. Reviews themselves were not affected.
What changes
- The installer finds a harness command on PATH instead of timing it. This holds for
gemini,claudeandagyalike, in both copies of the installer. --versionis still asked once, with a limit of 30 seconds. A command that is found but gives no answer in that time still counts as installed, and the installer says that it did not answer. Claude Code and Antigravity are then linked by their folder links. Gemini is linked by its owngemini skills link: if that command gives no answer within 30 seconds either, the skill is not linked, the installer names the command and does not start it again, and an update stops.- A command that is not on PATH is skipped as before, and nothing is created for it. A command that is found but whose
--versionreports a failure is not linked, as before, and the installer says what failed. The words "not installed" are gone. - When a harness cannot be verified, the updater gives the installer's own reason after
Harness replay did not verify, and afterInstaller replay failedwhen the installer itself reported a failure. It still stops, still claims nothing it could not verify, and still leaves the recovery command. When a harness was linked although its command did not print its version, the updater says so in a line that beginsNote:. - A version check that is ended by a signal is reported as
failed (killed by <signal>). - Onboarding's
--linkgives the installer 180 seconds instead of 45, so a harness command that answers nothing ends with the installer's whole reason and not with a stopped installer. updating.mdhas a section on what those messages mean, with a table of the outcomes and what to check.
Updating to 1.17.3 from 1.17.2 or earlier The updater that runs is the installed one, but it replays the installer of the release it has checked out, so the installer fix applies during this update. Its messages are still the old ones. If this update stops for another reason, the automatic recovery replays the older installer and can stop the old way: run the retained rollback command again when the machine is less busy. The retained recovery copy stays the older updater until the update after this one.
Known limits. A harness command that answers every call, but only after 18 to 30 seconds each, can still exceed the updater's 180 seconds for one harness when many skills are linked through gemini skills link; onboarding's --link has the same 180 seconds. Preflight and --doctor still give a reviewer CLI five seconds to print its version; a slower one is reported as "Version check inconclusive" and not ready, never as not installed. The updater does not check whether a review is running from the installed copy while it updates it: do not update while one is. The new code paths for macOS and Linux were first run on the hosted matrix; the whole pack was run by the maintainer's harness on Windows only. The limits listed in the 1.17.2 notes stand.
Details: gate record and finding · updating