#3319·Solaar

Keep volatile session state like _config_cookie out of config.yaml

Author: paolomainardiCreated Sep 4, 2026Updated Sep 4, 2026

Information

  • Solaar version (solaar --version): 1.1.20 (Arch package solaar 1.1.20-2)
  • Distribution: Arch Linux
  • Kernel version: Linux 7.1.8-arch1-3 x86_64 GNU/Linux
  • Device: MX Master 3S (Bolt receiver)

Is your feature request related to a problem? Please describe.

Since #3173, Solaar persists the end-of-configuration session cookie into ~/.config/solaar/config.yaml as _config_cookie. The cookie changes on every settings apply (device reconnect, resume from suspend, any settings push), so the file is rewritten constantly.

I keep ~/.config under version control (dotfiles managed with yadm). config.yaml is the natural file to track because it holds the actual device settings, but _config_cookie makes it permanently dirty: every boot produces a diff like

diff
-  _config_cookie: [114, 38]
+  _config_cookie: [114, 47]

Runtime keys such as _battery already caused occasional churn, but the cookie makes the drift constant.

Describe the solution you'd like

Store volatile per-session state outside the settings file, for example in $XDG_CACHE_HOME/solaar/ or $XDG_STATE_HOME/solaar/, keyed by device serial. config.yaml would then contain only user-chosen settings plus stable identity keys, and would only change when the user changes something.

The cookie is explicitly session-scoped (the dedup gate in apply_settings_if_needed must not trust it across power cycles, per the comment in lib/logitech_receiver/device.py), so a cache or state directory seems like a better fit than the persisted configuration.

Describe alternatives you've considered

  • A git clean filter that strips _config_cookie (and _battery) lines before commit. It works, but it has to be rediscovered and maintained by anyone versioning their dotfiles.
  • Untracking config.yaml entirely, which loses versioning of the real settings.

Additional context

Happy to send a PR moving the cookie (and possibly the other underscore-prefixed runtime keys) to a separate state file if the approach sounds acceptable.