exec ignores window rules

[non-bin]

Window rules don't seem to work in the latest nix flake (maybe related to #12269). Both of the following just open the program like a normal window on the active workspace:

$ hyprctl dispatch exec "[workspace 3] spotify" # My use case
$ hyprctl dispatch exec "[workspace 2 silent; float; move 0 0] kitty" # Example from docs
$ Hyprland -v
Hyprland 0.52.0 built from branch unknown at commit e584a8bade2617899d69ae6f83011d0c1d2a9df7 dirty (unknown).
Date: 2025-11-22
Tag: v0.52.0, commits: 0

Libraries:
Hyprgraphics: built against 0.3.0, system has unknown
Hyprutils: built against 0.10.2, system has unknown
Hyprcursor: built against 0.1.13, system has unknown
Hyprlang: built against 0.6.5, system has unknown
Aquamarine: built against 0.9.5, system has unknown

no flags were set

[vaxerski]

they work for me. What OS are you on?

[lichie567]

I am also experiencing this issue. Some rules work, and some don't. I use a script to launch my terminal in a dedicated spot on one of my side monitors like this: hyprctl dispatch exec "[size 1277 718; monitor DP-3; rounding 0; move 1281 721;]" $TERMINAL. The rules for size and the monitor works, but rounding and move rules do not work. It seems that pre-existing rules from my hyprland config file are interfering with rules passed with exec. Before the recent rules rework an exec command with explicit rules included seemed to ignore all rules defined in your config. Also to be clear this is happening with kitty as my terminal, which is running wayland native. No xwayland involved.

[lichie567]

Here are the relevant configs that should be needed to repro my issue:

# hyprland.conf

decoration {
    rounding = 10
}

# All windows float by default
windowrule = float on, match:class .*

# By default, launch kitty on my main monitor, centered, 1800x1200
windowrule = monitor DP-2, match:class kitty
windowrule = center on, match:class kitty
windowrule = size 1800 1200, match:class kitty

Here is the command I use to alternatively launch kitty on my side monitor

# term.sh

hyprctl dispatch exec "[size 1277 718; monitor DP-3; rounding 0; move 1281 721;]" "$TERMINAL"

Expected behavior: term.sh should launch kitty on my side monitor (DP-3, which is 1440p) in the bottom right corner, with no window rounding, size 1277x718 (1/4 of the screen but with space for window borders).

Actual behavior: term.sh correctly launches kitty on DP-3 with size 1277x718, but it launches centered on that monitor, with window rounding enabled.

In my previous comment I said exec seemed to ignore rules before but after closer inspection while making this post thats obviously not true. But there does seem to be some change in how the rules are merged. My guess is somehow the center and move rules are being applied differently than before, and now the center rule is perhaps taking precedence despite being defined "first". I'm not exactly sure what is going on with rounding. I already reverted back to the hyprland package from the arch repos because I didn't have time to do deeper troubleshooting, but I will reinstall hyprland-git when I have some free time.

[non-bin]

it might be. Can you exec an xwayland app, then hyprctl clients, find its pid, and attach cat /proc/[PID_OF_THE_APP]/environ?

$ spotify &
$ hyprctl clients
...
Window 55e50ccf0680 -> Spotify Premium:
	mapped: 1
	hidden: 0
	at: 4,49
	size: 954,1147
	workspace: 3 (3)
	floating: 0
	pseudo: 0
	monitor: 0
	class: spotify
	title: Spotify Premium
	initialClass: spotify
	initialTitle: Spotify Premium
	pid: 8779
	xwayland: 0
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags:
	swallowing: 0
	focusHistoryID: 1
	inhibitingIdle: 0
	xdgTag:
	xdgDescription:
	contentType: none
...
$ cat /proc/8779/environ
onePlatform --ozone-platform=wayland --enable-wayland-ime=true
$ kill 8779 # this didn't work, maybe it's operating on the wrong pid?
$ pidof .spotify-wrapped
8952 8844 8842 8840 8805 8804 8779
$ # Killing all of them did nothing either, so I used my close window key combo

$ hyprctl dispatch exec "spotify"
$ hyprctl clients
...
Window 55e50d85a880 -> Spotify Premium:
	mapped: 1
	hidden: 0
	at: 4,49
	size: 954,1147
	workspace: 3 (3)
	floating: 0
	pseudo: 0
	monitor: 0
	class: Spotify
	title: Spotify Premium
	initialClass: Spotify
	initialTitle: Spotify
	pid: 11291
	xwayland: 1
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags:
	swallowing: 0
	focusHistoryID: 2
	inhibitingIdle: 0
	xdgTag:
	xdgDescription:
	contentType: none
...
$ cat /proc/11291/environ
by-spotify-1.2.63.394.g126b0d89/share/spotify/.spotify-wrapped

$ hyprctl dispatch exec "[workspace 1 silent] spotify"
$ hyprctl clients
...
Window 55e50ce53840 -> Spotify Premium:
	mapped: 1
	hidden: 0
	at: 4,49
	size: 954,1147
	workspace: 3 (3)
	floating: 0
	pseudo: 0
	monitor: 0
	class: Spotify
	title: Spotify Premium
	initialClass: Spotify
	initialTitle: Spotify
	pid: 10224
	xwayland: 1
	pinned: 0
	fullscreen: 0
	fullscreenClient: 0
	grouped: 0
	tags:
	swallowing: 0
	focusHistoryID: 1
	inhibitingIdle: 0
	xdgTag:
	xdgDescription:
	contentType: none
...
$ cat /proc/10224/environ
by-spotify-1.2.63.394.g126b0d89/share/spotify/.spotify-wrapped

$ whereis spotify
spotify: /nix/store/v886fr7v922cydh444b3px2w9bck8mxx-user-environment/bin/spotify
$ cat /nix/store/v886fr7v922cydh444b3px2w9bck8mxx-user-environment/bin/spotify
# LD_LIBRARY_PATH stuff
exec -a "$0" "/nix/store/w59aw02psnzd866i5ilb1dnsn8xkqvby-spotify-1.2.63.394.g126b0d89/share/spotify/.spotify-wrapped"  ${NIXOS_OZONE_WL:+${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime=true}} "$@"

[lichie567]

@vaxerski after digging into the code and debugging, it seems the issue is that the HL_INITIAL_WORKSPACE_TOKEN from the currently focused workspace is applied to windows spawned with the exec dispatcher, which causes window rules from that workspace to be applied to new windows even when they are being launched on a different workspace via rules passed to exec.

Additionally, at window spawn time, the center rule seems to override any move rules regardless of ordering. Maybe this is intended but it is not the same behavior as before, where a move rule would override a center rule if it came after. Perhaps the move rule should be deprecated for a position rule that can accept either a coordinate pair or center as params.

I also cannot get any dynamic rules to be applied via rules passed to exec. I can see that the rules are being parsed and processed in CWindowRuleApplicator::applyDynamicRule, but for some reason the rules do not take effect.

[non-bin]

Great work! thank you :)