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.
Light themes render foot colors into [colors-dark], so foot reports dark mode to 996-aware TUIs
Reported by rubas · filed Aug 29, 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
Omarchy 4.0.1, foot 1.27.0, theme Flexoki Light.
What happens
TUIs that ask the terminal for its color-theme mode render in dark mode on every light Omarchy theme, even though the terminal background is light. Observed with hunk (hunk.dev), which uses the contour color-scheme protocol (CSI ?996n query, mode 2031 for updates). foot 1.27 supports this protocol.
Why
default/themed/foot.ini.tpl renders every theme's palette into the [colors-dark] section:
[colors-dark]
foreground={{ foreground_strip }}
background={{ background_strip }}
...foot's convention (foot.ini(5), foot-ctlseqs(7)) is that [colors-dark] is the dark theme and [colors-light] is the light theme, and it answers CSI ?996n with CSI ?997;1n (dark) whenever the primary/dark theme is active. So with Flexoki Light the background is FFFCF0 but foot still reports "dark" to applications.
The theme already declares its mode: colors.toml has mode = "light". The template just does not use it.
Suggested fix
When mode = "light", render the palette into [colors-light] instead and set initial-color-theme=light in the generated include (or have the default foot.ini set it). Then foot reports CSI ?997;2n and 996/2031-aware TUIs pick the right mode.
Repro
omarchy theme set flexoki-light(or any theme withmode = "light").- In foot, run a 996-aware TUI, e.g.
hunk diff. - It renders dark.
printf '\033[?996n'shows foot replying?997;1n(dark).
View raw text
Omarchy 4.0.1, foot 1.27.0, theme Flexoki Light.
## What happens
TUIs that ask the terminal for its color-theme mode render in dark mode on every light Omarchy theme, even though the terminal background is light. Observed with hunk (hunk.dev), which uses the contour color-scheme protocol (`CSI ?996n` query, mode 2031 for updates). foot 1.27 supports this protocol.
## Why
`default/themed/foot.ini.tpl` renders every theme's palette into the `[colors-dark]` section:
```ini
[colors-dark]
foreground={{ foreground_strip }}
background={{ background_strip }}
...
```
foot's convention (foot.ini(5), foot-ctlseqs(7)) is that `[colors-dark]` is the dark theme and `[colors-light]` is the light theme, and it answers `CSI ?996n` with `CSI ?997;1n` (dark) whenever the primary/dark theme is active. So with Flexoki Light the background is `FFFCF0` but foot still reports "dark" to applications.
The theme already declares its mode: `colors.toml` has `mode = "light"`. The template just does not use it.
## Suggested fix
When `mode = "light"`, render the palette into `[colors-light]` instead and set `initial-color-theme=light` in the generated include (or have the default `foot.ini` set it). Then foot reports `CSI ?997;2n` and 996/2031-aware TUIs pick the right mode.
## Repro
1. `omarchy theme set flexoki-light` (or any theme with `mode = "light"`).
2. In foot, run a 996-aware TUI, e.g. `hunk diff`.
3. It renders dark. `printf '\033[?996n'` shows foot replying `?997;1n` (dark).
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 09:51 UTC