screen saver triggers keepassxc lock ubuntu/gnome as cause ? Quick Answer The cause is that KeePassXC on Linux/GNOME typically monitors the session idle state (via D-Bus signals like org.gnome.ScreenSaver ) rather than the specific "screen lock" event. On many Ubuntu/GNOME configurations, the session is considered idle or the screensaver state changes when the screen blanks , triggering KeePassXC to lock the database immediately. This creates a conflict when users set the "Blank Screen" delay to be shorter than the "Automatic Screen Lock" delay. Because KeePassXC reacts to the blank/idle signal rather than the actual password prompt appearing, it locks the database prematurely. To resolve this, users often: • Set the Blank Screen delay in GNOME settings to Never or a value longer than the lock delay. • Use external tools like xss-lock or custom scripts to decouple the screensaver/blanking event from the session lock signal. • Switch to a desktop environment like KDE Plasma , which handles these events more distinctly, or use a different password manager that respects the actual lock screen state. elaborate Researched KeePassXC screen lock behavior How KeePassXC Detects Lock on Linux KeePassXC's ScreenLockListenerDBus.cpp watches two D-Bus signals: Signal Bus What it means org.freedesktop.Scree nSaver.ActiveChanged (and org.gnome.ScreenSaver ) Session bus Screen saver / blank state changed Signal Bus What it means org.freedesktop.login 1.Session.Lock System bus Session actually locked by logind On GNOME, the problem is that ActiveChanged fires when the screen blanks , not when the password prompt appears. These are two separate events in GNOME, controlled by different timers: Timer gsettings key Default Screen blank delay org.gnome.desktop.ses sion idle-delay 300 s Lock delay (after blank) org.gnome.desktop.scr eensaver lock-delay 0 s Lock enabled? org.gnome.desktop.scr eensaver lock-enabled true So when the screen goes dark at 300 s, ActiveChanged fires → KeePassXC locks. The actual session lock (which might be 300 + 300 = 600 s later) is a separate event that KeePassXC also listens for, but it's already too late. The "Cancelled Fade" Bug There's an additional GNOME bug where the lock signal is emitted as soon as the fade-out animation starts , even if you move the mouse and cancel the lock. So KeePassXC locks even though you never actually left your seat. Workarounds 1. Use KeePassXC's own inactivity timer instead Disable "Lock databases when session is locked or lid is closed" (Tools → Settings → Security) and set a fixed inactivity timeout (e.g. 600 s). This is the simplest fix but locks based on KeePassXC inactivity, not system-wide idle. 2. Adjust GNOME blank/lock delays # Never blank (keeps screen on, defeats the purpose) gsettings set org.gnome.desktop.session idle-delay 0 # Or: blank at 10 min, lock 0 s after blank (so blank == lock) gsettings set org.gnome.desktop.session idle-delay 600 gsettings set org.gnome.desktop.screensaver lock-delay 0 Setting lock-delay to 0 makes the lock happen at the same moment as the blank, so the two events coincide and the behaviour is at least consistent. 3. D-Bus script for precise control You can bypass the built-in listener and drive locking manually via D-Bus: # Lock dbus-send --session --print-reply \ --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc \ org.keepassxc.KeePassXC.MainWindow.lockAllDatabases # Unlock (password from gnome-keyring via secret-tool) tmp_passwd=$(secret-tool lookup keepass mydb) dbus-send --session --print-reply \ --dest=org.keepassxc.KeePassXC.MainWindow /keepassxc \ org.keepassxc.KeePassXC.MainWindow.openDatabase \ string:/path/to/mydb.kdbx string:$tmp_passwd Pair this with a dbus-monitor watcher on org.gnome.ScreenSaver to auto-unlock when the session unlocks (see the grabski.me guide ). 4. On MATE / other DEs The relevant key is org.mate.desktop.session idle-delay (not the screensaver setting, despite the GUI placement). A user on Linux Mint forums confirmed that raising this to 43200 s (12 h) stopped the premature lock. Status This is a known, open issue ( #6493 ). The KeePassXC maintainers acknowledge it but consider changing the behaviour a security regression (locking earlier than the actual lock is "safer"). No fix is planned — the workarounds above are the current options. Does KDE Plasma fix this issue? Checked KDE Plasma KeePassXC lock fix Yes, KDE Plasma handles this correctly. The key difference is that Plasma separates the screen blank and the lock into two independent, configurable events: • System Settings → Screen Locking → "Lock screen automatically" (delay before the session is locked) • System Settings → Screen Locking → "Delay before password required" (how long after the lock before a password is actually demanded) KeePassXC's "Lock database when session is locked" reacts to the actual lock event , not the blank event. So you can set the screen to blank after 2 minutes while the session lock stays at 1 hour, and KeePassXC will only lock the database when the session actually locks. This is confirmed by user reports — one on the Linux Mint forums noted that after hitting the same issue on Cinnamon (which behaves like GNOME here), they tried KDE and it "worked as expected." The root cause on GNOME/Cinnamon/MATE is that those desktops conflate "session idle" (which fires when the screen blanks) with "session locked," and KeePassXC listens to the idle signal. KDE Plasma's kscreenlocker emits distinct signals for blank vs. lock, so the two don't interfere.