Repository navigation
Switching from rc back to stable (4.5.0-rc1 → 4.0.6) breaks saved workspace layouts and mise tool shims #16282
Description
What happened
I switched to the rc channel with omarchy channel set rc, which installed 4.5.0-rc1. A few hours later I switched back with omarchy channel set stable, which downgraded to 4.0.6. The rc's migrations had changed user state in ways 4.0.6 can't use, and nothing undoes those changes, which broke two things.
1. Saved workspace layouts break the Hyprland config
With 4.5.0-rc1, omarchy-hyprland-workspace-layout-toggle (Super+L) saves layouts as:
o.workspace_mode({ workspace = "1", mode = "scrolling" })4.0.6 loads the same directory (default/hypr/workspace-layouts.lua) but doesn't define o.workspace_mode. So after switching back, Hyprland shows the "Your config has errors" overlay, with one line per saved layout:
require("omarchy.workspace-layouts.1"): ~/.local/state/omarchy/workspace-layouts/1.lua:1: attempt to call a nil value (field 'workspace_mode')
2. Agent CLIs and dev tools stop working (mise "No version is set for shim")
4.5.0-rc1 ships /etc/mise/conf.d/omarchy-tools.toml, which declares codex, gh, node and other tools. Its migration removes those tools from ~/.config/mise/config.toml and deletes their ~/.local/bin wrappers. Switching back to stable removes /etc/mise/conf.d/omarchy-tools.toml but restores neither the user config entries nor the wrappers. The tools stay installed, but every shim fails:
$ codex
mise ERROR No version is set for shim: codex
Set a global default version with one of the following:
mise use -g codex@0.155.1
...
The same happened for gh, node, and k6, which I had added to my global mise config myself.
Expected
Switching back from rc to stable leaves a working system, for example:
- 4.0.6 skips saved layout files it can't load, or the layout format stays readable by both versions.
- The tool declarations or wrappers that the rc migration removed are restored, or the user config is left alone.
Steps to reproduce
- On 4.0.6, have codex or gh set up through mise, and toggle a workspace layout with Super+L.
- Run
omarchy channel set rc(installs 4.5.0-rc1), then toggle a layout again. - Run
omarchy channel set stable(downgrades to 4.0.6). - Reload Hyprland: the error overlay appears. Run
codexorgh: the mise shim error appears.
Workaround
- Rewrite each
~/.local/state/omarchy/workspace-layouts/N.luaashl.workspace_rule({ workspace = "N", layout = "<mode>" }), or delete the files. - Add the tools back with
mise use -g codex@latest gh@latest node@latest.
System
- Omarchy 4.0.6-1 (stable, after 4.5.0rc1-1 on the rc channel)
- mise 2026.10.17
- Hyprland 0.56.2
- Kernel 7.2.8-9-omarchy
Possibly related: #15876 (leave the user's mise config alone), #16204 (Kimi wrapper the lazy-shim migration missed).
Activity
omarchybot commentedon Oct 23, 2026
I reproduced both failures on a disposable Omarchy VM. It was running current
quattro(967bbdd), so every 4.5 migration had already run. I saved a layout with the toggle, which wroteo.workspace_mode({ workspace = "1", mode = "scrolling" }). Thenomarchy-channel-set stableinstalled omarchy and omarchy-settings 4.0.6-1 and removed/etc/mise/conf.d/omarchy-tools.toml.Layouts. Checked with
Hyprland --verify-configagainst 4.0.6's config, it fails with exactly your error:workspace-layouts/1.lua:1: attempt to call a nil value (field 'workspace_mode'). Rewriting the same file in the oldhl.workspace_rule(...)form makes it pass withconfig ok. The cause is migration1791698594(new in 4.5.0-rc1). It rewrites every saved layout too.workspace_mode, and the new toggle writes that form too. The function only exists in 4.5'sdefault/hypr/workspace-modes.lua, and 4.0.6'sdefault/hypr/workspace-layouts.lualoads the saved files without it. The loader stops at the first file that fails, so the layouts after it don't load either.mise tools. After the switch,
codexandnodeprintNo version is set for shim, andghprintsgh is not a valid shim. Migration1791382872deletes the stock~/.local/binwrappers and runsmise unuse -g --no-prunefor each default tool's@latestentry, and1792343099does the same fornode@latest. Both rely onomarchy-tools.tomldeclaring those tools instead. Going back to 4.0.6 removes that file. The migrations are already marked as run, and 4.0.6's update only runsmise up, so nothing puts the declarations or wrappers back. Your workaround (mise use -g codex@latest gh@latest node@latest) is the right repair for now.k6. Neither I nor the second opinion could explain k6 from the source. No 4.5 migration touches it, and the cleanup only removes the default tools'
@latestentries. If it is still broken after the workaround,mise ls --globalandmise doctoroutput would show where its entry went.More of the same. The second opinion found four other 4.5-only migrations that should break a return to 4.0.6 in the same way. I checked that each one is in 4.5.0-rc1 and not in 4.0.6, but I did not reproduce them:
1791969355splits the bar's center section, which 4.0.6's bar does not know.1788129995removes Tensaku, which 4.0.6's screenshot editor still launches.1792343225drops the user'supgrade.auto_prune = false, which 4.0.6's mise config does not set.1790528634renames the Elsewhen plugin to an ID that 4.0.6 does not ship.Nothing in
omarchy-channel-setor the docs promises or warns about going from rc back to stable. A fix needs one of these:Choosing among them is a decision for the maintainer, so I have not opened a pull request. This is labelled
bugand is waiting on the maintainer.Checked by Claude Opus 5.5, with second opinions from Codex Medium and muse-spark-1.3-contributor via pi, thinking high. Both agreed with both causes. Independence is not guaranteed, but the four extra migrations came from Codex.