Repository navigation
Autobackup not considering all open windows? #118
Description
Unfortunately I can`t prove it but i suspect the autobackup does not save the state of all open windows.
With autobackup enabled/loaded i lost all my open browser instances / links.
I use those to persist things but every session just showed the wmux webpage. Would be awesome if autobackup could also backup these. I had an old saved session and with that i was able to at least recover some of my pages.
Activity
amirlehmam commentedon Jul 28, 2026
Fixed in 43e049a, shipping in v0.37.0. You were right, and it was worse than "does not save all windows" — it actively destroyed the state of every window but one, every 30 seconds.
The bug
Auto-save is a broadcast. Main sends
session:requestto every window, and each renderer answers with its own state, wrapped as a one-entry array because that's the file's shape:That payload went straight into
saveSession(data)— which writes the whole file. So with two windows open, both answered, and whichever answered last overwrote the other one's entry. Every 30 seconds, and again on quit. There was never a merge step; the format had room for N windows and the write path only ever held one.The same
windows[0]assumption sat on the read side.SESSION_LOAD_AUTOhanded the first window's state to whoever asked, so a second window came up as a clone of the first's tabs rather than its own, and a multi-window session could never restore more than one window's worth of state anyway.On the browser pages specifically
Those are stored per surface (
surface.url, persisted into the split tree since #40), so they were never the weak link — they went down with the rest of the window's entry when it got clobbered. Which also explains the shape of what you saw: not "browser tabs are special and don't persist", but "one window's whole tree survived and the other's didn't", and the surviving one showed the default page because it was a different window.That you had to recover from an old named session fits exactly: named saves are explicit single-window snapshots and never went through the broadcast, so they were the only thing the race couldn't touch.
The fix
SessionWindowRegistrygives each window a slot. A save upserts one slot and serialises all of them; restore hands each window back its own; launch reopens every saved window (capped at 8, so a corrupt file can't spawn windows without bound).Two cases deliberately do not prune a window's slot, and both matter:
Closing window 2 of 3 does forget it, immediately and on disk, so a window you deliberately closed doesn't come back as a ghost.
Tests cover the merge, the ordering (creation order, not who-answered-first), priming a restored window that never reports, and both no-prune cases.
One behaviour change worth flagging
A new window (
Ctrl+Shift+Norwmux new-window) now opens empty instead of duplicating your first window's workspaces. That was the read-side half of this bug, but if you'd gotten used to it as a "duplicate this window" gesture, it's gone.For what it's worth, the suspicion was enough. Thanks for filing it anyway rather than writing it off.
arnonuem commentedon Jul 28, 2026
"launch reopens every saved window (capped at 8, so a corrupt file can't spawn windows without bound)."
What does this mean? I usually have about 20 sessions open :/
I expect them to be opened all of them when I launch wmux.
fix(session): stop multi-window auto-save clobbering itself
fix(cli): scope V2 commands to the caller's workspace, reject unknown…