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.
omarchy-system-stats reports wildly wrong (negative) CPU% under decimal-comma locales (es_ES, etc.)
Reported by sanchon · filed Sep 17, 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
The CPU percentage shown by the bar's system stats (consumed by the "Analytics" bar widget, and any other consumer of omarchy-system-stats with no arguments) shows huge negative values, e.g. -873%, -579%.
Root cause
/usr/bin/omarchy-system-stats (no-arg path) parses top -bn1 output with awk:
cpu=$(top -bn1 | awk '/^%?Cpu/ {
gsub(/,/, "")
for (i = 1; i <= NF; i++) {
if ($(i + 1) == "id") {
printf "%.0f%%", 100 - $i
exit
}
}
}')Under locales where LC_NUMERIC uses a comma as the decimal separator (e.g. es_ES.UTF-8, and most of Europe/Latin America), top prints the idle percentage with a comma instead of a period:
%Cpu(s): 5,6 us, 3,4 sy, 0,0 ni, 84,3 id, 4,5 wa, 1,1 hi, 1,1 si, 0,0 stThe script's gsub(/,/, "") strips every comma — including the decimal separator — turning 84,3 into 843. The subsequent 100 - 843 produces a large negative number, which is what gets displayed as the CPU percentage.
Steps to reproduce
# with a decimal-comma locale
LC_NUMERIC=es_ES.UTF-8 LANG=es_ES.UTF-8 omarchy-system-stats
# cpu -8xx% (varies with actual load)Or just be running Omarchy with LANG=es_ES.UTF-8 / LC_NUMERIC=es_ES.UTF-8 (or any other decimal-comma locale) and open the bar's Analytics/system-stats CPU readout.
Expected
A sane CPU percentage (0-100), independent of locale.
Suggested fix
Force LC_NUMERIC=C for the top invocation (or parse more carefully instead of blanket-stripping commas), e.g.:
cpu=$(LC_NUMERIC=C top -bn1 | awk '/^%?Cpu/ {
gsub(/,/, "")
for (i = 1; i <= NF; i++) {
if ($(i + 1) == "id") {
printf "%.0f%%", 100 - $i
exit
}
}
}')The --bar-widget path in the same script (which reads /proc/stat directly via awk) is unaffected, since it doesn't go through top's locale-formatted output.
System details
- Omarchy version: 4.0.4-1
- Locale:
LANG=es_ES.UTF-8,LC_NUMERIC=es_ES.UTF-8 - Affected file:
/usr/bin/omarchy-system-stats(no-arg / non--bar-widgetpath)
Workaround applied locally
Set LC_NUMERIC=C globally via Hyprland's hl.env (in ~/.config/hypr/envs.lua), which fixes it for this and any other locale-sensitive command spawned in the session, without touching the packaged script.
View raw text
## What happened
The CPU percentage shown by the bar's system stats (consumed by the "Analytics" bar widget, and any other consumer of `omarchy-system-stats` with no arguments) shows huge negative values, e.g. `-873%`, `-579%`.
## Root cause
`/usr/bin/omarchy-system-stats` (no-arg path) parses `top -bn1` output with awk:
```bash
cpu=$(top -bn1 | awk '/^%?Cpu/ {
gsub(/,/, "")
for (i = 1; i <= NF; i++) {
if ($(i + 1) == "id") {
printf "%.0f%%", 100 - $i
exit
}
}
}')
```
Under locales where `LC_NUMERIC` uses a comma as the decimal separator (e.g. `es_ES.UTF-8`, and most of Europe/Latin America), `top` prints the idle percentage with a comma instead of a period:
```
%Cpu(s): 5,6 us, 3,4 sy, 0,0 ni, 84,3 id, 4,5 wa, 1,1 hi, 1,1 si, 0,0 st
```
The script's `gsub(/,/, "")` strips *every* comma — including the decimal separator — turning `84,3` into `843`. The subsequent `100 - 843` produces a large negative number, which is what gets displayed as the CPU percentage.
## Steps to reproduce
```bash
# with a decimal-comma locale
LC_NUMERIC=es_ES.UTF-8 LANG=es_ES.UTF-8 omarchy-system-stats
# cpu -8xx% (varies with actual load)
```
Or just be running Omarchy with `LANG=es_ES.UTF-8` / `LC_NUMERIC=es_ES.UTF-8` (or any other decimal-comma locale) and open the bar's Analytics/system-stats CPU readout.
## Expected
A sane CPU percentage (0-100), independent of locale.
## Suggested fix
Force `LC_NUMERIC=C` for the `top` invocation (or parse more carefully instead of blanket-stripping commas), e.g.:
```bash
cpu=$(LC_NUMERIC=C top -bn1 | awk '/^%?Cpu/ {
gsub(/,/, "")
for (i = 1; i <= NF; i++) {
if ($(i + 1) == "id") {
printf "%.0f%%", 100 - $i
exit
}
}
}')
```
The `--bar-widget` path in the same script (which reads `/proc/stat` directly via awk) is unaffected, since it doesn't go through `top`'s locale-formatted output.
## System details
- Omarchy version: 4.0.4-1
- Locale: `LANG=es_ES.UTF-8`, `LC_NUMERIC=es_ES.UTF-8`
- Affected file: `/usr/bin/omarchy-system-stats` (no-arg / non `--bar-widget` path)
## Workaround applied locally
Set `LC_NUMERIC=C` globally via Hyprland's `hl.env` (in `~/.config/hypr/envs.lua`), which fixes it for this and any other locale-sensitive command spawned in the session, without touching the packaged script.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 15:00 UTC