Mercury CLI
Building Mercury inside Mercury
I’m making a harness that I want to use. What I’ve noticed over the past few updates is how much time I’m spending on my own harness. The debugging and evaluation tools feel better, and it feels rewarding after working on it for so long.
The beta.17 release notes include fixes found while using Mercury to develop Mercury. Among them was a search failure that could leave an agent looking elsewhere when the code it needed was already present.
A search that missed existing files
On macOS, Grep could miss files matching anchored globs when searching through a symlinked folder. The files existed, but the spelling of the search root affected whether the tool found them.
An empty result can send an investigation elsewhere without looking like a tool failure. For a model locating Mercury’s own implementation, that can misdirect the work before an edit has even been proposed.
The fix passes the search root’s real path to ripgrep. Returned file references are then translated back to the spelling supplied to Grep, keeping them consistent with the folder the session is using.
The tagged regression test searches through both the real folder and its symlink. It checks root-anchored and directory-anchored patterns, then checks the references returned with the results. That last part matters for the following edit: the search should leave the model referring to the same files it just inspected.
Keeping the replacement intact
Earlier releases had addressed another fault between a model’s request and the resulting code.
The bundled changelog records Edit converting straight quotes into typographic quotes inside code when the file already contained some. Beta.15 restricted quote-style preservation to prose. Beta.16 extended the correction to files whose language was not recognised.
A replacement could therefore be correct when requested and acquire unwanted punctuation when written. Reviewing the proposed code alone would miss that distinction. The editing tool also needed to preserve the quote characters through the write.
That is a practical complication of developing Mercury inside Mercury: a problem in the resulting source can originate in the tool applying the patch.
Tests launched from a Mercury session
Running Mercury’s checks from inside Mercury introduces another boundary: the environment inherited by the command.
The beta.5 release changed shell commands to remove Mercury’s internal session markers. It also added a guard that refuses to start proof suites with unexpected Mercury settings in their environment.
A running session carries configuration for its own work. Allowing those values to reach a test can change the conditions under which the test runs. The harness launching the check needs to avoid supplying hidden inputs to the harness being checked.
The distinction is more precise than clearing every Mercury-related variable. The tagged shell tests check that session-generated values are removed while deliberately supplied user settings survive. They exercise the command-launch boundary as well as the helper that identifies which values to remove.
That gives the check a defined starting environment without silently discarding intentional configuration.
Reviewing a fixed commit
The review step uses two models from different companies as adversarial reviewers. The code under review also needs a defined state.
The reviewer documented in the beta.5 release reads a copy frozen at the reviewed commit, runs checks there and writes the review section of its report. Review comments and check results can then be tied back to the commit they examined while development continues elsewhere.
The same concern carries through to publishing. The release records place beta.16 on 21 September 2026 and beta.17 a little over twenty-four hours later, on 22 September 2026.
The beta.17 verdict records the hosted gate running on the release line’s published tree, with 137 of 137 release suites passing. The local pool after a clean install recorded 136 of 137.
Its failing check concerned messages sent around a sub-agent’s return joining under the same message identity. The release page records that it passed alone twice and remained recorded for beta.18. Those reruns do not erase the pooled failure.
The published release record states that each archive manifest is signed with Mercury’s release key.
That leaves a specific account of what shipped, what was checked and what remained unresolved. Using Mercury more often exposes more of its behaviour, including cases that a successful isolated check does not settle.
The same release page queues preserving a live runner across daemon restarts and writing the daemon’s supervisor record atomically for beta.18. Both concern keeping the development session reliable while the surrounding processes change.
Install
The release page carries the full changelog and verdict. The archives include their own Node runtime; installation needs git. Existing installations update with mercury update.
The release’s install command for macOS and Linux x64:
curl -fsSL https://mercury-cli.ai/install | sh
For Windows x64, the release specifies PowerShell 7:
irm https://mercury-cli.ai/install.ps1 | iex