On Hyprland, opening Cursor sets a Wayland idle inhibitor on the Agents window. The compositor then never reports the session as idle, so the desktop screensaver does not start no matter how long the keyboard and mouse are unused.
Closing Cursor releases the inhibitor and the screensaver runs on schedule. Reopening Cursor sets the inhibitor again.
On Wayland that wakelock is session-wide. It blocks the screensaver for every app, and there is no setting to turn it off. I could not find an existing report of this screensaver behavior.
Steps to reproduce
On Hyprland, set the screensaver to start after 60 seconds of idle time.
Open Cursor. The window title in this case was Cursor Agents.
Leave the keyboard and mouse idle for more than a minute.
Run hyprctl clients -j and look at inhibitingIdle.
Expected
The screensaver starts after the configured idle time. A wakelock, if one is needed, should be limited to an agent that is actually running, and there should be a way to turn it off.
Actual
The screensaver never starts while Cursor is open.
hyprctl clients -j shows inhibitingIdle: true only for the Cursor window (class cursor, title Cursor Agents). Other open apps (Brave, VeraCrypt) are inhibitingIdle: false.
Omarchy’s idle service honors that inhibitor, so its screensaver timer never begins. Closing Cursor clears the flag and the screensaver starts after 60 seconds. Reopening Cursor sets the flag again.
Environment
Cursor window class: cursor
Window title: Cursor Agents
Session: Wayland, Hyprland 0.56.2
Desktop: Omarchy 4.0.4 (Arch Linux)
Screensaver timeout: 60 seconds, confirmed in the shell idle settings
Stay-awake was off. No other client was inhibiting idle.
Hey, thanks for the detailed report and the hyprctl output.
This looks like it’s coming from Chromium, which Cursor is built on, not from the agent wakelock. The wakelock Cursor takes while the agent is running is a suspend inhibitor via D-Bus, it doesn’t create a Wayland idle inhibitor. Starting with Chromium 146, Chromium apps on Wayland started setting a Wayland idle inhibitor on normal windows. The same behavior is reported for Chromium and Brave windows on Hyprland and Omarchy, and Cursor moved to that Chromium version in the 3.19 release.
As a temporary workaround, running Cursor via XWayland should bypass this. Can you test?
Fully close Cursor and make sure there are no cursor processes left.
In a terminal, run cursor --ozone-platform=x11
Open the Agents window, then leave keyboard and mouse idle for over a minute.
Run hyprctl clients -j and check inhibitingIdle for the Cursor window.
Let me know whether the screensaver starts and what inhibitingIdle shows, plus your Cursor version Help > About and whether this started after an update. If XWayland works, adding the flag to the Exec line in your .desktop file will make it stick. Keep in mind the text may look a bit softer with fractional scaling.
Version: Cursor 3.21.16, Electron 42.9.3, Chrome 148.0.7778.280. Hyprland 0.56.2, Omarchy 4.0.4. This is past the 3.19 release you mentioned. I do not have a before/after update date for when the inhibitor first appeared.
Beforecursor --ozone-platform=x11, hyprctl clients -j for the Agents window:
class cursor, title Cursor Agents
xwayland: false
inhibitingIdle: true
After launching with that flag, the same Agents window:
xwayland: true
inhibitingIdle: false
process argv includes --ozone-platform=x11 ahead of cursor.mjs
The screensaver did start with this workaround. Once the Agents window was on XWayland, leaving the keyboard and mouse idle brought the screensaver up on schedule.
The flag is only on this process. A normal launch without it is native Wayland again, and the inhibitor comes back.
Follow-up after living with the XWayland workaround.
Making the flag stick. Adding --ozone-platform=x11 only to the .desktopExec line is not enough. Some launchers exec the cursor binary and never read that file. On Omarchy, the Editor shortcut runs omarchy editor, which starts uwsm-app -- cursor from the configured editor name. That path ignored the desktop override and came back as native Wayland with inhibitingIdle: true.
The Arch Cursor launcher reads ~/.config/cursor-flags.conf on every start and appends those lines to the Electron command. This covers the shortcut, the menu, and a terminal:
--ozone-platform=x11
A fresh launch with no extra command-line flag then showed xwayland: true and inhibitingIdle: false. The process has to be fully quit first. An already-running native Wayland instance just absorbs the new launch.
Put the override in ~/.local/share/applications/ rather than /usr/share/applications/, or the next package update restores the stock Exec line. Do not put the flag in the editor-name file itself. Omarchy treats that whole line as the command name and falls back to a terminal editor.
Text side effect. On XWayland the text looks different (weight and size). Hyprland here has xwayland:force_zero_scaling enabled, so X11 clients are not given the fractional monitor scale and render at scale 1. GTK apps hide that with GDK_SCALE. Cursor is Electron and ignores it. Native Wayland Cursor had been rasterizing at the monitor scale.
The same flags file can set Chromium’s scale without leaving XWayland, so the idle inhibitor stays off:
SCALE has to match the compositor monitor scale (hyprctl monitors -j). A mismatch makes the whole UI too large or too small. Dropping only that line keeps the screensaver workaround and returns the scale-1 XWayland text.
Removing cursor-flags.conf and any user desktop overrides returns Cursor to native Wayland, and the inhibitor comes back.
