Learn
How can a terminal session survive a reboot?
Terminal sessions die because the shell's lifetime is tied to whatever displays it: close the window or drop the SSH connection and the work is gone. Decouple those two lifetimes and the session outlives the screen. Here is how Termuna does it, and what honestly survives a full reboot.
Why do sessions normally die with the screen?
In a classic setup, the shell is a child of the thing that shows it. Close the terminal window and the process group goes with it. Lose the SSH connection and the remote shell gets hung up. Tools like tmux exist precisely to break that coupling on one machine; the moment you want the same session on another device, you are back to reattaching by hand over a connection that can itself drop.
What owns the session when no window is open?
In Termuna, a small daemon on your machine owns the real shells and the authoritative session tree: which tabs exist, how they are split, what runs where. Windows, browsers, and phones are all just viewers attached to it. Closing the app closes a viewer, not the shell. The build that was running keeps running, because nothing it depended on went away.
What gets mirrored to the cloud?
When sync is on, the daemon attaches sessions to the relay as an encrypted host. Two things flow up as they happen: sealed frames, meaning every byte of output and input encrypted on your machine before the network (how that works), and the current layout, so a viewer joining late can draw the right tabs and splits immediately. The relay persists both durably, so history is there even after the relay itself restarts.
What happens when a viewer reconnects?
Every frame carries a sequence number, and each viewer tracks the last one it rendered. After a dropped connection, the viewer asks the relay for everything since that sequence and replays the gap. If the relay can no longer serve that stretch of history, the viewer falls back to a full resync instead of showing a corrupted in-between state. Either way you end up looking at exactly what the session looks like now.
What survives a full reboot, honestly?
A reboot kills processes. No sync system changes that, and claims otherwise deserve suspicion. What Termuna preserves is everything around the processes: the full scrollback history, stored encrypted in the cloud, and the complete workspace, meaning tabs, splits, and each pane's working directory. After the machine comes back, the desktop app resurrects that layout into fresh shells with a single click. Your long-running build is gone; the room you did it in, with everything you saw on the way, is not.
Which machine resurrects the workspace?
The one that rebooted. Resurrection means the desktop app on your machine recreates the tabs, splits, and working directories as fresh local shells; your other devices stay what they always were, viewers of that machine's sessions. The daemon reconnects to the cloud with its device token, the same revocable credential it always uses, so a reboot changes nothing about who can see what. And because the session keys never left your devices, the rebooted machine decrypts its own history the same way it always did; the relay still holds nothing but ciphertext.
What does this look like in practice?
- Close the laptop mid-build: the build keeps running on the machine. Open your phone and watch it finish.
- Train tunnel kills the network: reconnect, the viewer replays the gap, nothing is missing.
- Kernel update forces a reboot: history is intact, and one click rebuilds every tab and split with the working directories you had.