Repository navigation
Canceling Windows VM setup leaves launcher in installed state #7943
Description
System details
- 11th Gen Intel Core i5-1145G7
- Intel Iris Xe Graphics
- Omarchy 4.0.0-1
- Linux 7.1.8-arch1-3, x86_64
What is wrong?
Canceling the Windows VM installer at its final "Proceed with this configuration?" prompt leaves the Omarchy launcher in an installed state. The launcher then offers "Launch Windows" and "Remove Windows" instead of "Install Windows", even though no VM was created.
Steps to reproduce
- Open the Omarchy launcher and choose Install > Windows.
- Complete the RAM, CPU, disk, username, and password prompts.
- Answer No at "Proceed with this configuration?".
- Reopen the Omarchy launcher.
Actual behavior
The installer exits, but ~/.local/share/applications/windows-vm.desktop remains. The launcher uses this file as its installed-state marker, so Install > Windows disappears while Launch > Windows and Remove > Windows appear. No docker-compose.yml, omarchy-windows container, dockurr/windows image, or ~/Windows shared folder exists.
Expected behavior
Canceling should leave the launcher offering Install > Windows and should not advertise a launchable/removable VM.
Cause and suggested fix
In bin/omarchy-windows-vm, install_windows creates windows-vm.desktop before any configuration prompts. All later cancellation paths exit without removing it. Current upstream still has this ordering.
Create the desktop entry only after the final confirmation (ideally after the compose file is created and startup succeeds), or add cancellation/error cleanup that removes the premature marker.
Workaround verified
Moving the stale windows-vm.desktop aside immediately restores Install > Windows. The two empty directories ~/.windows and ~/.config/windows can remain and are reused on retry.
Activity
brian commentedon Sep 11, 2026
Just ran into this as well. Glad there's a pending fix.
Drop the setgid removal test that omacom#12323 already covers
omarchybot commentedon Oct 8, 2026
Thanks for the precise report. The cause you named is right, and it is still there on
quattro(c352b62d):install_windowswrites~/.local/share/applications/windows-vm.desktopatbin/omarchy-windows-vm:1173, before any prompt. Every later exit leaves it behind, and nothing cleans it up: cancelling RAM, CPU or disk selection, Ctrl+C, declining "Proceed with this configuration?" (line 1304), a failed configuration or credential write, and a failedpriv up. The menu treats that file as the installed marker (default/omarchy/omarchy-menu.jsonc:220and:304). Onlyremove_windowsdeletes it.This is already fixed by #12264, which is linked to this issue and will close it when merged. That pull request writes the launcher entry only after the VM has started successfully. It was run on a worker built from the Omarchy ISO, where both of its launcher tests fail against
quattroand pass on its head.One limit: the fix stops new stale entries but does not remove one an earlier cancellation already left behind. Until then, your workaround is the right one:
rm ~/.local/share/applications/windows-vm.desktopbrings back Install > Windows.This was checked by Claude Opus 5.5 and by Codex Medium as a second opinion. Codex agreed with the diagnosis and that #12264 covers every exit path. It also raised the point about entries left behind by earlier cancellations. It can read this session, so its independence is not guaranteed. Nothing was run for this issue; the reproduction is the one recorded on #12264. This now waits on the maintainer's decision about #12264.