vendored xlings: the note that no newer source is available can be false, and it is printed once per configuration load

[speak-agent]

Summary

When the vendored xlings (<home>/registry/bin/xlings) is older than the version mcpp pins, acquire_xlings_binary (src/fallback/xlings_binary.cppm) looks for a newer source and either replaces the binary (Updating vendored xlings A -> B) or keeps it and prints:

        Note vendored xlings 2026.9.29.1 is older than the pinned 2026.9.30.1, but no newer source is available (keeping it; run `xlings self update`)

Two defects follow from how the check is made:

1. The note can be false. candidate_source_version returns the version of the first source that exists, in the order MCPP_VENDORED_XLINGS, the xlings released beside the running mcpp (<prefix>/registry/bin/xlings), then xlings on PATH. It does not take the newest of them. When the released copy is older than the pin and a newer xlings is on PATH, mcpp states that no newer source is available and keeps the older binary.
2. The note is printed once per configuration load, not once per command. The check runs in config::load_or_init(), which is not memoised and is called from about ten call sites (the pack pipeline, each member's prepare, the fetcher, and others). One mcpp pack --format release over a workspace printed the note three times per member.

Measurement

The cross-verification of #743 on the validation project (Sunrisepeak/GalTranslPP, run 36643197950, Windows) installs the released mcpp 2026.9.29.5 and replaces only its mcpp.exe with a build of the pull request branch, whose pin is xlings 2026.9.30.1. The xlings beside it is the 2026.9.29.1 that the 2026.9.29.5 release shipped. The same job installed xlings v2026.9.30.1 with quick_install.ps1 and put %USERPROFILE%\.xlings\bin on PATH. The build printed the note above, repeatedly, although a newer xlings was on PATH.

Scope

A release does not reach this state: its archive ships the pinned xlings beside mcpp. An mcpp installed with xlings install (home ~/.mcpp) whose vendored copy is older finds the released copy first, prints Updating once, and is quiet afterwards; a self-contained home's vendored copy is the released one. The state arises when the released copy is older than the pin, as in the cross-verification layout, a hand-replaced binary, or a development build placed in an older release directory.

vendored	released beside mcpp	on PATH	today	expected
older	pinned	any	one Updating	unchanged
older	older	newer	Note (false), repeated	one Updating from PATH
older	absent	newer	one Updating per load	one Updating
older	older	older	Note, repeated	one Note

Proposed change

• One function selects the source: MCPP_VENDORED_XLINGS when it is set; otherwise the newer of the released copy and the PATH copy, the released copy on a tie. The check and the copy both use its answer, so the version stated is the version copied.
• The rule that a vendored binary is replaced only by a strictly newer one is kept, so an old system xlings still cannot downgrade it.
• Updating and Note are each stated at most once per process.

Criteria

An e2e test with three stub xlings binaries that print a version:

• vendored older, released older, PATH newer: one Updating line, and the vendored binary is then the PATH one;
• vendored older, released newer, PATH older: the released copy is taken;
• all three older than the pin: one Note line;
• a command that loads the configuration more than once prints the line once.

Found during the 2026.9.30.1 cycle (#743); it does not affect that release.

[speak-agent]

Fixed in mcpp 2026.9.30.2 (#745, released with #747).

• One function chooses the source of a vendored xlings: MCPP_VENDORED_XLINGS when it is set, otherwise the newer of the xlings released with mcpp and the xlings on PATH, the released copy on a tie. The check that decides whether to replace the vendored binary and the copy that replaces it both use that answer, so the version stated is the version copied.
• A home settled once in a process is not examined again: Updating and Note are each stated at most once per process.
• The version of the vendored binary is asked once per process and kept under the home (<home>/cache/vendored-xlings.versions), keyed by the binary's path, size and modification time, so a command that loads its configuration no longer runs xlings --version (0.35 s measured) when the binary has not changed. An upgrade copies beside the binary and renames over it, so a failed copy keeps the old binary.

Criteria:

• e2e 846: vendored older, released older, PATH newer gives one Updating ... from PATH line; released newer, PATH older takes the released copy; everything older gives one Note. It fails on 2026.9.30.1 with the false note of this issue.
• Unit tests: the source choice in every case, the memo (asked once, read without running the binary, a new file asked again), and one Note for two acquisitions in one process.
• Sandbox verification against the published release (.agents/docs/2026-09-30-build-wall-time-verify.sh, section 6): section 6 passes against the published 2026.9.30.2 in an xlings sandbox (xlings subos use v9302 --sandbox, CN mirror for xlings and mcpp): a newer xlings on PATH replaced the vendored one past an older released copy. The full script: 10 of 10 sections pass.