Proof Portal

Sign in
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-4778GitHub issuePublicReceived

VS Code/Cursor never reloads generated "Omarchy" color theme — theme changes don't propagate and re-selecting it applies a stale palette

Reported by Macho0x · filed Aug 31, 2026Closed upstream on 2026-09-04 by its own reporter Macho0x. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

VS Code/Cursor never reloads generated "Omarchy" color theme — theme changes don't propagate and re-selecting it applies a stale paletterevision 1 · captured 2026-10-04 12:03 UTC via poll

Summary

omarchy-theme-set-vscode ships a generated "Omarchy" color theme extension for VS Code / Cursor, but VS Code-family editors load a theme file once and cache it in memory (and in profile storage). Nothing in the pipeline invalidates that cache, so:

  1. With "Omarchy" selected as the color theme, switching to a new Omarchy theme never updates the editor palette.
  2. After choosing a manual theme (e.g. Dracula), re-selecting "Omarchy" as a VS Code / Cursor color theme applies the stale palette cached at first load, not the current system one.

Not Cursor-specific: same path affects VS Code, Code-Insiders, VSCodium.

Root cause (confirmed against VS Code source)

  • ColorThemeData.ensureLoaded() is a no-op after first load. A reload only happens via (a) the file watcher (requires private _watch: true on the contribution), or (b) the theme registry added delta, or (c) selecting a different theme — but the registry instance persists, so switching back uses the in-memory cached copy.
  • Omarchy rewrites ~/.cursor/extensions/omarchy-theme/package.json and extensions.json with byte-identical content on every omarchy theme set → no extension-scan delta → no reload. (_watch is not set.)
  • If "Omarchy" is already selected, the sed rewrite of workbench.colorTheme produces the same value → no config change event → restoreColorTheme never runs.

Secondary issue: window.autoDetectColorScheme makes Omarchy writes inert

When window.autoDetectColorScheme: true, VS Code routes the effective theme setting to workbench.preferredDarkColorTheme/preferredLightColorTheme (ThemeConfiguration.getColorThemeSettingId()) and ignores workbench.colorTheme — the key Omarchy edits. All Omarchy theme writes then silently do nothing. Omarchy should also write the preferred-theme keys or warn when this setting is on.

Tertiary issue: silent third-party extension install failures

The vscode.json route runs "$editor_cmd" --install-extension "$extension" >/dev/null 2>&1. When the install fails (e.g. marketplace unreachable, extension unavailable for the fork), the theme is set to a name that does not exist and the failure is invisible.

Steps to reproduce

  1. omarchy theme set a generated-theme palette (one without vscode.json, e.g. a palette-only theme).
  2. In Cursor/VS Code set Color Theme to "Omarchy" — correct colors.
  3. Install a third-party theme (e.g. Dracula) and select it.
  4. In the Color Themes picker re-select "Omarchy" → stale colors (whatever was cached at first load), not the current system palette.
  5. omarchy theme set a different palette-only theme → Cursor does not update even with "Omarchy" selected.

Suggested fixes

  • Bump the generated extension version on each theme set (e.g. timestamped) so extensions.json/package.json genuinely change → scan delta → theme registry added event → reload. Most robust.
  • Or add "_watch": true to the generated contribution (note: current/theme is swapped via mv, which may break the inode watch — needs testing).
  • Handle window.autoDetectColorScheme (write preferred-theme keys too, or warn).
  • Stop swallowing --install-extension failures.

System details

  • Omarchy: 4.0.2-1 (also present on 3.x)
  • OS: Omarchy / Arch, kernel 7.1.9-arch1-2
  • Cursor: 3.17.21 (VS Code 1.128), also reproducible in VS Code / Code-Insiders / VSCodium
  • CPU: 11th Gen Intel Core i7-1165G7, GPU: Intel Iris Xe
  • Hyprland 0.56.2

<img width="1358" height="473" alt="Image" src="https://github.com/user-attachments/assets/38b3961e-ec71-4cda-b0da-cb462458a5ab" />

View raw text
## Summary

`omarchy-theme-set-vscode` ships a generated "Omarchy" color theme extension for VS Code / Cursor, but VS Code-family editors load a theme file **once** and cache it in memory (and in profile storage). Nothing in the pipeline invalidates that cache, so:

1. With "Omarchy" selected as the color theme, switching to a new Omarchy theme never updates the editor palette.
2. After choosing a manual theme (e.g. Dracula), re-selecting "Omarchy" as a VS Code / Cursor color theme applies the stale palette cached at first load, not the current system one.

Not Cursor-specific: same path affects VS Code, Code-Insiders, VSCodium.

## Root cause (confirmed against VS Code source)

- `ColorThemeData.ensureLoaded()` is a no-op after first load. A reload only happens via (a) the file watcher (requires private `_watch: true` on the contribution), or (b) the theme registry `added` delta, or (c) selecting a different theme — but the registry instance persists, so switching back uses the in-memory cached copy.
- Omarchy rewrites `~/.cursor/extensions/omarchy-theme/package.json` and `extensions.json` with byte-identical content on every `omarchy theme set` → no extension-scan delta → no reload. (`_watch` is not set.)
- If "Omarchy" is already selected, the `sed` rewrite of `workbench.colorTheme` produces the same value → no config change event → `restoreColorTheme` never runs.

## Secondary issue: `window.autoDetectColorScheme` makes Omarchy writes inert

When `window.autoDetectColorScheme: true`, VS Code routes the effective theme setting to `workbench.preferredDarkColorTheme`/`preferredLightColorTheme` (`ThemeConfiguration.getColorThemeSettingId()`) and ignores `workbench.colorTheme` — the key Omarchy edits. All Omarchy theme writes then silently do nothing. Omarchy should also write the preferred-theme keys or warn when this setting is on.

## Tertiary issue: silent third-party extension install failures

The `vscode.json` route runs `"$editor_cmd" --install-extension "$extension" >/dev/null 2>&1`. When the install fails (e.g. marketplace unreachable, extension unavailable for the fork), the theme is set to a name that does not exist and the failure is invisible.

## Steps to reproduce

1. `omarchy theme set` a generated-theme palette (one without `vscode.json`, e.g. a palette-only theme).
2. In Cursor/VS Code set Color Theme to "Omarchy" — correct colors.
3. Install a third-party theme (e.g. Dracula) and select it.
4. In the Color Themes picker re-select "Omarchy" → stale colors (whatever was cached at first load), not the current system palette.
5. `omarchy theme set` a different palette-only theme → Cursor does not update even with "Omarchy" selected.

## Suggested fixes

- Bump the generated extension version on each theme set (e.g. timestamped) so `extensions.json`/`package.json` genuinely change → scan delta → theme registry `added` event → reload. Most robust.
- Or add `"_watch": true` to the generated contribution (note: `current/theme` is swapped via `mv`, which may break the inode watch — needs testing).
- Handle `window.autoDetectColorScheme` (write preferred-theme keys too, or warn).
- Stop swallowing `--install-extension` failures.

## System details

- Omarchy: 4.0.2-1 (also present on 3.x)
- OS: Omarchy / Arch, kernel 7.1.9-arch1-2
- Cursor: 3.17.21 (VS Code 1.128), also reproducible in VS Code / Code-Insiders / VSCodium
- CPU: 11th Gen Intel Core i7-1165G7, GPU: Intel Iris Xe
- Hyprland 0.56.2

<img width="1358" height="473" alt="Image" src="https://github.com/user-attachments/assets/38b3961e-ec71-4cda-b0da-cb462458a5ab" />
  • 38b3961e-ec71-4cda-b0da-cb462458a5ab

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.

No decision has been recorded yet.