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.
`{{ muted }}` is used as both a text color and a fill in the generated VS Code theme
Reported by ivanskodje · filed Sep 3, 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
System details
Intel i9-12900H, Intel Iris Xe + NVIDIA RTX 3070 Ti Laptop, Omarchy 4.0.0.alpha, VS Code 1.135.0
What's wrong?
TLDR: in the generated VS Code theme, muted is the color of comments and line numbers, and it is also the fill behind buttons whose label is {{ foreground }}. One of those jobs needs it light, the other needs it dark. It ends up dark, so comments are hard to read, causing an accessibility problem.
I am wondering whether you would want them split before anyone writes a patch?
I have been building an Omarchy Tokyo Night Storm theme, and in VS Code the comments and line numbers come out very faint. It traces back to muted.
docs/theming.md describes muted as "de-emphasized elements (comments, placeholders, dividers); also serves as ANSI color8", and default/themed/vscode-theme.json.tpl uses it that way for comments, line numbers, breadcrumbs, inactive tabs and placeholders. It is also the fill behind button.secondaryBackground, commandCenter.activeBackground and extensionButton.background, each of which puts a {{ foreground }} label on top of it.
Those two jobs seem to want opposite things. As text it needs to be light enough to read on the window background. As a fill it needs to be dark enough for a {{ foreground }} label to read on top of it. No single value does both.
<img width="1701" height="1381" alt="Image" src="https://github.com/user-attachments/assets/bdea81c6-9eb8-45d5-8250-47d8c3d34728" />
That is the generated theme rendering the official Tokyo Night palette that comes with Omarchy. The comments there have a contrast ratio of 1.91:1 against the background, where WCAG asks 4.5:1 for body text. The shipped tokyo-night theme does not normally look like this, because it carries a vscode.json pointing VS Code at enkia's port, and 16 of the 22 shipped themes do the same. The six that actually render this file are ethereal, lupine, miasma, ristretto, vantablack and white, where comments sit between 2.57:1 and 4.90:1.
It also applies to themes installed from a git repo, which cannot ship a vscode.json because it is on INSTALLED_THEME_DENIED, so Omarchy selects the generated theme for them. Picking a different VS Code theme by hand works, but omarchy-theme-set-vscode rewrites workbench.colorTheme on the next theme switch unless skip-vscode-theme-changes is set, which stops VS Code following theme switches at all.
Tokyo Night Storm keeps the two apart, with separate values for line numbers, comments, inactive tabs, the secondary button fill and ANSI 8.
One option would be to derive the comment token instead, for example {{ mix background foreground 65% }}. Across those six themes that lands between 4.56:1 and 8.63:1 against the background while staying at least 1.9:1 dimmer than the surrounding code, and it needs no new palette key. It does however mean that comments lose whatever hue color8 gave them.
Is that something you would want changed, or is the current behavior intentional?
View raw text
### System details
Intel i9-12900H, Intel Iris Xe + NVIDIA RTX 3070 Ti Laptop, Omarchy 4.0.0.alpha, VS Code 1.135.0
### What's wrong?
**TLDR:** in the generated VS Code theme, `muted` is the color of comments and line numbers, and it is also the fill behind buttons whose label is `{{ foreground }}`. One of those jobs needs it light, the other needs it dark. It ends up dark, so comments are hard to read, causing an accessibility problem.
I am wondering whether you would want them split before anyone writes a patch?
---
I have been building an [Omarchy Tokyo Night Storm theme](https://github.com/ivanskodje/omarchy-tokyo-night-storm-theme), and in VS Code the comments and line numbers come out very faint. It traces back to `muted`.
`docs/theming.md` describes `muted` as "de-emphasized elements (comments, placeholders, dividers); also serves as ANSI `color8`", and `default/themed/vscode-theme.json.tpl` uses it that way for comments, line numbers, breadcrumbs, inactive tabs and placeholders. It is also the fill behind `button.secondaryBackground`, `commandCenter.activeBackground` and `extensionButton.background`, each of which puts a `{{ foreground }}` label on top of it.
Those two jobs seem to want opposite things. As text it needs to be light enough to read on the window background. As a fill it needs to be dark enough for a `{{ foreground }}` label to read on top of it. No single value does both.
<img width="1701" height="1381" alt="Image" src="https://github.com/user-attachments/assets/bdea81c6-9eb8-45d5-8250-47d8c3d34728" />
That is the generated theme rendering the official Tokyo Night palette that comes with Omarchy. The comments there have a contrast ratio of 1.91:1 against the background, where WCAG asks 4.5:1 for body text. The shipped `tokyo-night` theme does not normally look like this, because it carries a `vscode.json` pointing VS Code at enkia's port, and 16 of the 22 shipped themes do the same. The six that actually render this file are `ethereal`, `lupine`, `miasma`, `ristretto`, `vantablack` and `white`, where comments sit between 2.57:1 and 4.90:1.
It also applies to themes installed from a git repo, which cannot ship a `vscode.json` because it is on `INSTALLED_THEME_DENIED`, so Omarchy selects the generated theme for them. Picking a different VS Code theme by hand works, but `omarchy-theme-set-vscode` rewrites `workbench.colorTheme` on the next theme switch unless `skip-vscode-theme-changes` is set, which stops VS Code following theme switches at all.
[Tokyo Night Storm](https://github.com/enkia/tokyo-night-vscode-theme/blob/7c0f11eaef322f293621ca7befe462214b7ea468/themes/tokyo-night-storm-color-theme.json) keeps the two apart, with separate values for line numbers, comments, inactive tabs, the secondary button fill and ANSI 8.
One option would be to derive the comment token instead, for example `{{ mix background foreground 65% }}`. Across those six themes that lands between 4.56:1 and 8.63:1 against the background while staying at least 1.9:1 dimmer than the surrounding code, and it needs no new palette key. It does however mean that comments lose whatever hue `color8` gave them.
Is that something you would want changed, or is the current behavior intentional?
- bdea81c6-9eb8-45d5-8250-47d8c3d34728
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 10:39 UTC