Autobackup does its own thing

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.

fix(session): keep browser state in the update backup; feat(config): …

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:

workspaces: win.workspaces.map(w => ({
  title, customColor,
8000
 shell, cwd, splitTree,   // ← that's all it kept
})),

So browserUrl was dropped on the way in, and every workspace's browser came back on the default page. browserWidth and pinned went the same way, and it only ever read windows[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: SessionData never declared browserUrl/browserWidth even 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:

the update backup carries browserUrl, browserWidth and pinned, 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);
SessionData now declares those fields, so a future save path can't silently drop them again;
a manual save keeps pinned too, which only the auto-save was doing;
the post-update restore applies the session's 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: handleVersionChange runs 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.

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…

Navigation Menu

Repository navigation

Autobackup does its own thing #145

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Autobackup does its own thing #145

Description

Activity

amirlehmam commented on Aug 5, 2026

amirlehmam commented on Aug 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions