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-3420GitHub issuePublicReceived

Cannot disable theme's automatic active window border coloring

Reported by mr-scrpt · filed Oct 21, 2025Closed upstream on 2025-10-21. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not 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

Cannot disable theme's automatic active window border coloringrevision 1 · captured 2026-10-04 11:42 UTC via poll

System details

Omarchy 3.1.1

What's wrong?

What I am trying to do

I am trying to implement a custom, dynamic border color for the active window. My goal is to change the border color based on the active keyboard layout (listening to the activelayout IPC event).

The Problem

To implement this, I first must disable Omarchy's default behavior of applying the theme's color to the active border. The built-in Omarchy behavior conflicts with my custom script, creating a race condition and visible flickering every time the window focus changes.

My problem is that I cannot find a way to disable this default behavior.

Steps I have taken to disable the default behavior

I assumed the border color was set in the static configuration. I have located and commented out col.active_border and col.inactive_border in all relevant configuration files:

  1. The default config:
  • ~/.local/share/omarchy/default/hypr/looknfeel.conf
  1. All theme configs (including my active theme, Catppuccin):
  • ~/.local/share/omarchy/themes/catppuccin/hyprland.conf
  • (and all other theme folders...)
  1. The "active" theme symlink that Hyprland sources:
  • ~/.config/omarchy/current/theme/hyprland.conf

Expected Result

After commenting out all col.active_border definitions and performing a full Hyprland restart (logout and login), I expect the active window border to no longer be colored by the theme. It should fall back to a Hyprland default (e.g., a simple grey) and not change on focus.

Actual Result

The active window border still gets colored with my theme's active color (e.g., rgb(c6d0f5) for Catppuccin) every time the window focus changes.

This proves that the active border color is not being set by a static config file. It must be set by an unidentified active process (a compiled daemon, a binary launched from exec-once, etc.) that monitors the activewindow or focuswindow event and force-applies the theme color.

We have already debugged and ruled out:
* Waybar (was fully disabled, problem persisted)
* hyprfocus plugin (is not installed)
* Any .sh scripts in exec-once
* Hyprland's animation = border setting

The Question

How can I completely disable this hidden behavior? Is there a process or configuration I am missing that force-applies the active border color? I need to stop this mechanism so I can take full control of the general:col.active_border property with my own IPC script.

View raw text
### System details

Omarchy 3.1.1

### What's wrong?

### What I am trying to do

I am trying to implement a custom, dynamic border color for the active window. My goal is to change the border color based on the active keyboard layout (listening to the `activelayout` IPC event).

### The Problem

To implement this, I first must disable Omarchy's default behavior of applying the theme's color to the active border. The built-in Omarchy behavior conflicts with my custom script, creating a race condition and visible flickering every time the window focus changes.

My problem is that I **cannot find a way to disable** this default behavior.

### Steps I have taken to disable the default behavior

I assumed the border color was set in the static configuration. I have located and commented out `col.active_border` and `col.inactive_border` in **all** relevant configuration files:

1.  The default config:
    * `~/.local/share/omarchy/default/hypr/looknfeel.conf`
2.  All theme configs (including my active theme, Catppuccin):
    * `~/.local/share/omarchy/themes/catppuccin/hyprland.conf`
    * (and all other theme folders...)
3.  The "active" theme symlink that Hyprland sources:
    * `~/.config/omarchy/current/theme/hyprland.conf`

### Expected Result

After commenting out all `col.active_border` definitions and **performing a full Hyprland restart** (logout and login), I expect the active window border to **no longer** be colored by the theme. It should fall back to a Hyprland default (e.g., a simple grey) and not change on focus.

### Actual Result

The active window border **still** gets colored with my theme's active color (e.g., `rgb(c6d0f5)` for Catppuccin) every time the window focus changes.

This proves that the active border color is not being set by a static config file. It *must* be set by an unidentified active process (a compiled daemon, a binary launched from `exec-once`, etc.) that monitors the `activewindow` or `focuswindow` event and force-applies the theme color.

We have already debugged and ruled out:
* Waybar (was fully disabled, problem persisted)
* `hyprfocus` plugin (is not installed)
* Any `.sh` scripts in `exec-once`
* Hyprland's `animation = border` setting

### The Question

How can I **completely disable** this hidden behavior? Is there a process or configuration I am missing that force-applies the active border color? I need to stop this mechanism so I can take full control of the `general:col.active_border` property with my own IPC 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.

No decision has been recorded yet.