GNOME is working on a new session save-and-restore functionality that will reopen applications and return users to their previous workspace after logging back in. However, the feature will not be ready for GNOME 51, scheduled for release on September 16, 2026.
The work was presented at GUADEC 2026 by Adrian Vovk, a GNOME developer working on Red Hat’s desktop team.
The idea itself is simple. Instead of rebuilding a workspace manually after rebooting, users could continue closer to where they left off. So, GNOME wants to add an option similar to “Reopen Windows After Login.” Once enabled, the desktop would remember which applications were running, reopen them after the next login, and restore as much of their previous state as possible.
Additionally, the supported applications will be able to recover their own content. For example, a text editor could reopen documents, a browser could restore tabs, and another app could return to the page or view open before the session ended.
For reference, GNOME did have session restoration under X11, but its old Session Management Protocol, known as XSMP, was no longer suitable for the modern desktop. It relied on applications registering command-line instructions that the session manager would run during the next login.
According to Vovk, that approach had been broken in GNOME for years. It also did not fit well with sandboxed applications since the session manager stored and executed command lines. GNOME dropped the old mechanism along with its X11 session support.
The new replacement uses a desktop portal. Instead of keeping arbitrary commands, the session manager tracks applications by their application IDs and relaunches them using their .desktop files. When an app starts again, it can be told why it is being restored, such as after a login or crash.
Window restoration requires separate work on Wayland. Applications running under Wayland cannot freely choose where to place their windows, so GNOME is using the xdg_session_management_v1 protocol.
Under this design, an application requests a token from the compositor. Mutter stores the window-management state linked to that token, and the application supplies it again when the session is restored. Mutter then restores the corresponding window state instead of leaving each application to handle window placement.
According to Vovk, the larger obstacle is GTK and the application-facing API. GNOME needs a reliable way for applications to describe and recover their internal state without forcing every developer to build the system from scratch. GTK is expected to handle much of that work, including per-window state, periodic saving, and restoration before an application becomes active.
Additionally, the portal is not finished either. According to the presentation, KDE and Firefox developers have approved the portal’s main concepts, but some details still need work. GNOME already has a private backend API dating back to GNOME 50, though converting it to the desktop portal depends on the frontend being completed.
All this means GNOME 51 will contain important groundwork, particularly in Wayland and Mutter, but users will not get the complete session restoration feature. In other words, there is no confirmed release yet for the finished feature.
Still, the work is beyond a vague idea. The protocol exists, Mutter support is landing, the portal is being discussed across desktop projects, and GTK’s application API is taking shape.
Dang, that sucks! This feature is already baked in in KDE Plasma.