Repository navigation
another issue with save session? #134
Description
It seems that the absolute paths of the open terminal windows are not stored or restored.
I manually saved a session which had two terminals open with a path like D:... but after restore it was C:....
Since i use git work trees which sit on different disks and which are tied to wmux sessions that leaves a chaos behind because i need to find out what the original path was when i need to restore a session (because of an update maybe).
Can you please investigate this?
Activity
feat(integration): ask before writing to ~/.claude; fix stale icon an…
amirlehmam commentedon Jul 31, 2026
Investigated, reproduced in the code, fixed in v0.40.0. Your instinct was right — the paths genuinely were not being stored.
What was happening
A terminal in wmux carries two directories, and only one of them was ever persisted:
cwd— where the terminal was told to start. A spawn argument.currentCwd— where shell integration last saw it, updated on every prompt.Saved sessions serialised
cwd. For a tab you open the ordinary way,cwdisundefined— nothing told it where to start. So on restore every terminal fell through to a single, workspace-levelcwd... which is itself written by whichever pane reported a prompt most recently. Two terminals, one workspace, one value: last writer wins.That is why you saw
D:\becomeC:\. The workspace value was either empty or belonged to the other pane, and with nothing usable the shell fell back to its own default — your home directory, on C:.Worth being clear that this was not a rounding error. Every terminal in a workspace came back in the same place, and for your setup — worktrees on separate drives, one session per worktree — the directory is the identity of the session. Losing it does not degrade the restore, it makes the restore pointless, which is exactly how you described it.
The fix
A new
freezeSurfaceCwds()promotes each surface's live directory into its persisted one, per tab, for the copy of the tree that goes into the saved session. Both paths use it — the named session you save by hand, and the 30-second auto-save that survives an update.Two design points, since they are the reason this is safe:
It happens at save time, not on every prompt.
cwdis a spawn argument — a fact about how the terminal was born — and rewriting it live would be editing a running terminal's history. It is also passed as a prop into the hook that creates PTYs, so a value that changes every time youcdis asking for trouble.It freezes into a copy. The live store keeps its own
cwduntouched; only the snapshot collapses the two facts into one, because "where should this reopen?" is the only question a snapshot needs to answer. There is a test pinning exactly that invariant, alongside ones for two panes on different drives staying on different drives, background tabs being frozen too (not just the visible one), and a terminal that hascd-ed away from its start directory persisting where it is rather than where it began.If shell integration never reported for a tab — an unintegrated shell — that tab still falls back to the old behaviour. I would rather that be honest than guess.
Landed in 58f2301.
One thing I have not changed
While tracing this I confirmed the workspace-level
cwdreally does flap between panes: any pane reporting a prompt overwrites it, and that single value also drives the sidebar's git branch/PR display, the diff pane, and which.wmux.jsonquick-launch profiles load. With your two-drive setup those will still jump around depending on which terminal printed a prompt last. It is a separate bug from the one you reported and a behavioural change to fix — the workspace value arguably ought to follow the focused pane — so I have not bundled it in. Say the word and I will open an issue for it; if it is actively bothering you I would rather hear that than guess.arnonuem commentedon Jul 31, 2026
i will test it but i guess for now this should do the trick
fix(cwd): track a workspace's POSIX directory separately from its Win…
feat(session): resume Claude Code sessions on workspace restore (#186)