Repository navigation
Autobackup does its own thing #145
Description
Why does autobackup and autorestore behave differently from manual save and load?
When i save my session (before an update of wmux - and thanks god i did) it correctly saves the workdir paths of the sessions and the browser states per session. When i load this session after update all is now correctly restored.
But before update there is an autobackup now and after update an autorestore?
Either the autorestore is not triggered automatically or the autorestore does not restore the same things like manual restore.
At least browser-states are back to default (wmux github page).
I was on version 0.41.x - might be fixed now.
Activity
fix(session): keep browser state in the update backup; feat(config): …
amirlehmam commentedon Aug 5, 2026
You diagnosed this correctly — "the autorestore does not restore the same things like manual restore" is exactly what was happening, and it wasn't fixed in 0.41.x. Thanks for saving your session before updating, and for reporting it.
Root cause. On the first launch of a new version, wmux archives the volatile auto-session (
session.json, whose PTYs died with the old process) as a named session — "Auto-backup vX.Y.Z" — and then clears it. That backup is what the post-update startup restores, since there's no auto-session left to come back to. It's the safety net added in #113.The conversion was lossy.
backupAutoSession()copied 5 of the 8 fields the auto-save actually writes:So
browserUrlwas dropped on the way in, and every workspace's browser came back on the default page.browserWidthandpinnedwent the same way, and it only ever readwindows[0]— with two windows open, the second window's workspaces were gone entirely.Your manual save was unaffected because that path (
handleSaveSession) always wrote the full set. Same data, two writers, one of them incomplete — hence "does its own thing".The reason it survived this long:
SessionDatanever declaredbrowserUrl/browserWidtheven though the renderer has been writing them since the auto-save existed, so the type was a subset of the real payload and dropping fields looked correct to the compiler.Fixed in 0.44.0:
browserUrl,browserWidthandpinned, and every window's workspaces rather than just the first (multi-window layouts come back flattened into one window — losing the split is a smaller surprise than losing the tabs);SessionDatanow declares those fields, so a future save path can't silently drop them again;pinnedtoo, which only the auto-save was doing;terminalPrefs, which the Sessions-menu Load already did and the automatic path was skipping.Five regression tests cover the backup contents, so this can't quietly rot again.
Timing, so you know what to expect:
handleVersionChangeruns on the first launch of the new build, which means the backup taken when you update to 0.44.0 is already written by the fixed code — your browser state, pinned tabs and any second window survive this update. An "Auto-backup v0.41.x" file already sitting on disk can't be repaired retroactively; those fields were never written into it. If that one still holds tabs you want, load it and re-save it manually once on 0.44.0 and it'll be complete from then on.amirlehmam commentedon Aug 5, 2026
Shipped in v0.44.0. Reopen if the browser state still doesn't survive your next update.
merge(upstream): bring amirlehmam/wmux master (0.46.0) into oh-my-pi
fix(cwd): track a workspace's POSIX directory separately from its Win…
feat(session): snapshot the layout on a schedule, not only on a versi…