Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1546GitHub issuePublicDecided· Out of scope

windows-vm: install ignores host locale and always installs English Windows

Reported by reiemsanh · filed Aug 23, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

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

windows-vm: install ignores host locale and always installs English Windowsrevision 1 · captured 2026-09-28 21:24 UTC via poll

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 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:

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

Omarchy4.0.0-1
Kernel7.1.8-arch1-3
CPU12th Gen Intel Core i7-1265U
GPUIntel Alder Lake-UP3 GT2 [Iris Xe Graphics]
dockurr/windows6.05
Host localeLANG=en_US.UTF-8, VC Keymap de, X11 Layout de
Host timezoneEurope/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