bootstrap v2026.09.17-3
Windows 1.41.1
Fixed
-
-Doctorstopped at its first check.okandbroken, the two
verdicts the doctor exists to give, were never added to theValidateSet
onAdd-Result, so the probe shell's ownokthrew before a single tool
was looked at. Both are in the set now, green and red. -
starship promptreported "no prompt function" with the profile
loaded. A function'sDefinitionstarts with a newline, and the probe
answers onekey=valueper line - sofn:prompt=always arrived empty.
The definition is flattened onto one line before it is sent. -
The mise checks looked in the Linux data directory. Windows mise keeps
its shims under%LOCALAPPDATA%\mise\shims, which is what the mise phase
puts on the userPATH; the doctor looked in~\.local\share\mise\shims
and reported it missing on every machine. Andnode,goandjava
resolving tomise\installs\...ismise activateworking as intended -
it puts those ahead of the shims - so that isoknow, not a note. Only a
runtime from outside mise is flagged. -
Housekeeping threw on an empty download cache. On PowerShell 7,
Measure-Objectemits nothing at all for empty input, so
(... | Measure-Object -Sum).Sumis$null.Sum, which strict mode rejects.
That ran before the "nothing to prune" check, so a clean cache - the usual
case - was enough. Sizes are summed byFormat-Sizeinstead, which is
0.0 MBfor no files.
Linux 1.34.2
Fixed
-
Housekeeping still stopped mid-phase, past the journal fix in 1.34.1.
The actual point of failure was the very next line:flatpak uninstall --unused --dry-run.uninstallhas never had a--dry-run- that flag
exists only onflatpak prune, for an unrelated purpose (pruning the
OSTree object store, not listing installed-but-unused runtime refs) - so
the command errored withUnknown option --dry-runevery time, and the
samepipefail/set -e/2>/dev/nullcombination silenced it. There is
no safe read-only substitute:--noninteractiveimplies--assumeyeson
--unused, so scripting around the missing flag risked doing the removal
this phase promises never to do. The check is gone;flatpak uninstall --unusedby hand is still there to run and review before answering yes. -
--doctormisjudged three things that were actually fine.7zip's
expected command was hardcoded to7zz- that name is macOS's; apt's own
7zippackage puts7zon PATH here.~/.dotnet/toolswas checked
against PATH unconditionally, when the shell fragment itself only adds it
oncedotnet tool install -ghas created the directory - its absence is
the fragment working as intended, not broken. And carapace's completer
was checked for a function named_carapace; carapace 1.7 defines
_carapace_completerinstead, so a working completer was reported as
never initialised. -
@releasestools disappeared under WSL and other NAT'd or shared
addresses. Each one calls GitHub's API once, unauthenticated, to read
its latest tag - 60 requests/hour per source IP, easy to spend across the
20-plus tools this platform installs that way, and every one queued
behind the first failure came backfailedand was never installed, not
just delayed.GITHUB_TOKEN/GH_TOKEN(read the same asghitself
reads them) or agh auth loginraise that to 5000/hour; either is now
picked up automatically, computed once per run rather than per tool.
macOS 1.37.1
Fixed
-
github_latest_tagwas unauthenticated. GitHub's API allows 60
requests/hour per source IP without a token, shared with anything else on
the same address; every release-tracked tool this call is used for is
one more request against that budget.GITHUB_TOKEN/GH_TOKEN(read the
same asghitself reads them) or agh auth loginraise that to
5000/hour; either is now picked up automatically, computed once per run
rather than per tool. -
--doctor's carapace check looked for the wrong function. carapace
1.7 defines_carapace_completer, not_carapace- the fragment
registers it withcompdef _carapace_completer <every command it covers>. A working completer was reported as never initialised.