Repository navigation
ISO Node install pins an exact version; omarchy update never converges users onto latest #10820
Description
System details
Intel i5-9400H, UHD Graphics 630, Omarchy 4.0.2-1
What's wrong?
ISO / first-boot Node setup writes an exact mise pin. Network / runtime setup writes latest. omarchy update then runs mise up (not --bump), so those two cohorts never converge. ISO users also diverge from each other across ISO ages, because each image pins whatever tarball it shipped.
This is not a local breakage — Node 26.7.0 works — but it is a user-to-user version mismatch that omarchy update does not heal.
What I see on an ISO install
~/.config/mise/config.toml:
[tools]
codex = "latest"
gh = "latest"
go = "latest"
node = "26.7.0"
"npm:@xai-official/grok" = "latest"
"npm:playwright" = "latest"
opencode = "latest"mise ls --current node:
node 26.7.0 ~/.config/mise/config.toml 26.7.0
After omarchy update / mise up, mise reports:
mise Newer versions are available but do not match the configured version ranges:
node 26.7.0 → 26.8.1 (~/.config/mise/config.toml)
Run `mise outdated --bump` to view all, or `mise upgrade --bump` to update the configuration and upgrade.
Other mise tools on the same machine are latest and do move. Node is the exception because it came from the bundled tarball.
Why
install/user/mise-work.sh:
- ISO /
provision-ownerwith a bundled tarball:mise use -g node@"$NODE_VERSION"(exact pin, so the offline unpack is selected). - Any other run, or missing tarball fallback:
mise use -g node@latest.
bin/omarchy-update-mise (and the mup alias) then does:
MISE_MINIMUM_RELEASE_AGE=0 mise upThat respects the configured range. An exact pin stays frozen. latest keeps moving. There is no migration that retargets the ISO pin once the machine is online.
That sits oddly next to the comment on omarchy-update-mise that running omarchy update is the user asking for current versions now. Node from the ISO path is excluded from that.
Expected
After a normal omarchy update, ISO-installed Node should follow the same policy as the network path (and as gh / go / the other mise tools), so users do not stay split by install method or ISO vintage.
Pinning the bundled tarball for offline first boot is reasonable. Leaving that exact pin in ~/.config/mise/config.toml forever is what creates the split.
Not asking users to run mise upgrade --bump. That is mise's generic hint, not an Omarchy command. Omarchy never calls --bump.
Activity
CRinATL commentedon Sep 13, 2026
Confirming this, and adding a data point that I think sharpens the "ISO users
diverge from each other" part: the split is not even explained by Omarchy
version.
This machine was installed from an offline ISO on 2026-08-30 that shipped
omarchy 4.0.2-1— the same package version you report — and it pinned:with
/var/lib/omarchy/provisioning/packages/node-v26.8.1-linux-x64.tar.gzasthe retained tarball. You get
26.7.0from 4.0.2-1; I get26.8.1from4.0.2-1. So two images of the same release bundle different Node tarballs, and
each freezes its own — the divergence is per-image, not per-release, which
makes it invisible to anyone comparing
omarchy version.Still unfixed on 4.0.3-1:
install/user/mise-work.shis owned byomarchy 4.0.3-1with line 39 unchanged, andomarchy-update-miseis stilljust
MISE_MINIMUM_RELEASE_AGE=0 mise upwith no pin handling. Node sat at26.8.1 across 15
omarchy updateruns (first online update 2026-09-06,latest 2026-09-13), with the range warning each time I looked:
One note on the two PRs I found touching this, since they act at different
points rather than overlapping: #11656 rewrites the pin in
mise-work.shatinstall time, and
mise-work.shdoes not run again on an installed machine, soit closes the source of new pins without changing any config already written.
#10878 retargets during
omarchy update, gated on a retained provisioningtarball whose version matches the pin — on this box that tarball is still
present, so it would have fired here. Flagging it only because the installed
base is the part that needs the second mechanism.
(Unpinned locally with
mise use -g node@latest, now tracking 26.8.2.)omarchybot commentedon Oct 11, 2026
This is fixed on
quattro, in two parts, and neither has shipped in a release yet (the latest is v4.0.4).install/user/mise-work.shrewrite the bundled Node pin tolatestright after registering the tarball, so ISO andprovision-ownerinstalls end up withnode = "latest"like an online install.migrations/1790457067.sh, which rewrites an exactnode = "X.Y.Z"line in~/.config/mise/config.tomltonode = "latest".omarchy updateruns migrations (bin/omarchy-update:129) beforeomarchy-update-mise(:141), so the same update that applies it also moves Node forward. Ranges such as"26"or"lts"are left alone.Both configs quoted here (
node = "26.7.0"andnode = "26.8.1") are the exact form the migration matches. Neither pull request was linked to this issue, which is why it is still open.What I checked: I read the installer, the migration and the update ordering at the current
quattrohead, and confirmed withgit tag --containsthat neither commit is in v4.0.4. Nothing was run on a worker, because there was nothing left to reproduce. Codex Medium reviewed it as a second opinion and reached the same conclusion. It also pointed out that the migration only matches mise's own one-line form in the global config, so a hand-written variant, like a different spacing, a quoted key or a[tools.node]table, would be left pinned. The migration also loosens an exact Node pin a user set on purpose. Neither affects the configs reported here.This waits on the maintainer to close it, now or once the next release ships with these commits.
jandrusk commentedon Oct 13, 2026
This is fixed on
quattrovia #11656 (rewrite offline Node pin tolatest). It may not be in a tagged release yet (still on v4.0.4 last I checked) — once that ships, safe to close.