Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
windows-vm: install ignores host locale and always installs English Windows
Reported by reiemsanh · filed Aug 23, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
What happened
omarchy-windows-vm install always installs English (en-US) Windows, regardless of the host's locale or keyboard layout.
The generated ~/.config/windows/docker-compose.yml sets only:
VERSION: "11"
TZ: "Europe/Berlin" # derived from the hostThe script already localises the timezone (omarchy-windows-vm:188) but passes no language, region, or keyboard, even though the host clearly declares them — on my machine localectl reports VC Keymap: de and X11 Layout: de.
What I expected
An install that follows the host's locale, or at minimum prompts for it alongside the existing RAM / CPU / disk / username prompts.
Why it happens
The compose file written by install_windows() (omarchy-windows-vm:182) sets no LANGUAGE, so dockur falls back to English (define.sh:142, LANGUAGE="en") and downloads the hardcoded ..._CLIENT_CONSUMER_x64FRE_en-us.iso.
The install language is baked into that ISO. It cannot be corrected afterwards without installing language packs, and the regional format stays US — so a non-English user has to reinstall to get a correctly localised system.
Steps to reproduce
- On a non-English host (e.g.
localectlshowingX11 Layout: de), runomarchy-windows-vm install - Wait for the install to finish, then launch the VM
- Windows is English with US regional format, regardless of host locale
Workaround
Adding the locale variables to ~/.config/windows/docker-compose.yml and reinstalling gives a correctly localised system:
LANGUAGE: "de"
REGION: "de-DE"
KEYBOARD: "de-DE"dockur then requests the German ISO from Microsoft and rewrites UILanguage, SystemLocale, UserLocale and InputLocale in the generated answer file accordingly. Verified working.
Note this edit is lost as soon as omarchy-windows-vm install is re-run, since it regenerates the compose file from scratch.
Suggested fix
Derive LANGUAGE / REGION / KEYBOARD from the host the same way TZ already is (localectl or $LANG), or add a gum choose prompt next to the existing ones.
System details
| Omarchy | 4.0.0-1 |
| Kernel | 7.1.8-arch1-3 |
| CPU | 12th Gen Intel Core i7-1265U |
| GPU | Intel Alder Lake-UP3 GT2 [Iris Xe Graphics] |
dockurr/windows | 6.05 |
| Host locale | LANG=en_US.UTF-8, VC Keymap de, X11 Layout de |
| Host timezone | Europe/Berlin |
omarchy debug --no-sudo --print is referenced in the contributing docs but does not exist in 4.0.0-1 (Unknown Omarchy command), so the above was collected manually.
View raw text
### What happened `omarchy-windows-vm install` always installs **English (en-US)** Windows, regardless of the host's locale or keyboard layout. The generated `~/.config/windows/docker-compose.yml` sets only: ```yaml VERSION: "11" TZ: "Europe/Berlin" # derived from the host ``` The script already localises the timezone (`omarchy-windows-vm:188`) but passes no language, region, or keyboard, even though the host clearly declares them — on my machine `localectl` reports `VC Keymap: de` and `X11 Layout: de`. ### What I expected An install that follows the host's locale, or at minimum prompts for it alongside the existing RAM / CPU / disk / username prompts. ### Why it happens The compose file written by `install_windows()` (`omarchy-windows-vm:182`) sets no `LANGUAGE`, so dockur falls back to English (`define.sh:142`, `LANGUAGE="en"`) and downloads the hardcoded `..._CLIENT_CONSUMER_x64FRE_en-us.iso`. The install language is baked into that ISO. It cannot be corrected afterwards without installing language packs, and the regional format stays US — so a non-English user has to reinstall to get a correctly localised system. ### Steps to reproduce 1. On a non-English host (e.g. `localectl` showing `X11 Layout: de`), run `omarchy-windows-vm install` 2. Wait for the install to finish, then launch the VM 3. Windows is English with US regional format, regardless of host locale ### Workaround Adding the locale variables to `~/.config/windows/docker-compose.yml` and reinstalling gives a correctly localised system: ```yaml LANGUAGE: "de" REGION: "de-DE" KEYBOARD: "de-DE" ``` dockur then requests the German ISO from Microsoft and rewrites `UILanguage`, `SystemLocale`, `UserLocale` and `InputLocale` in the generated answer file accordingly. Verified working. Note this edit is lost as soon as `omarchy-windows-vm install` is re-run, since it regenerates the compose file from scratch. ### Suggested fix Derive `LANGUAGE` / `REGION` / `KEYBOARD` from the host the same way `TZ` already is (`localectl` or `$LANG`), or add a `gum choose` prompt next to the existing ones. ### System details | | | |---|---| | Omarchy | 4.0.0-1 | | Kernel | 7.1.8-arch1-3 | | CPU | 12th Gen Intel Core i7-1265U | | GPU | Intel Alder Lake-UP3 GT2 [Iris Xe Graphics] | | `dockurr/windows` | 6.05 | | Host locale | `LANG=en_US.UTF-8`, VC Keymap `de`, X11 Layout `de` | | Host timezone | Europe/Berlin | `omarchy debug --no-sudo --print` is referenced in the contributing docs but does not exist in 4.0.0-1 (`Unknown Omarchy command`), so the above was collected manually.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 08:30 UTC