Restore a workspace#
Current Automexia source can preserve useful workspace layout and bounded terminal history between launches. This is not process hibernation: restored tabs open fresh shells, and saved commands are never rerun. Verify the feature in your development build; website downloads are withdrawn.
What can be restored#
The snapshot can include windows, window tabs, splits, pane-local tabs, selection, working folders, window geometry, and custom tab titles/colors. Up to the latest 10,000 physical lines per terminal may be retained with text styles, wrapping, and completed-command metadata, subject to workspace size limits. Restored history remains scrollable above a clearly marked new shell.
The default smart startup choice appears for useful prior work, such as several sessions, sustained command activity, or integrated SSH activity. A brief idle window normally does not displace an older useful checkpoint. Choose Restore to reopen the layout or Start clean for a new workspace. The menu's Restore previous session can also be used when startup did not prompt. A manual restore opens additional windows; it does not replace the work you are doing now.
Work through common situations#
- You closed a project window: reopen Automexia and choose Restore if offered. Inspect the retained build output, then rerun only the commands you deliberately choose.
- A remote pane was open: the history can show what happened, but the new pane is local. Run
sshagain and review authentication/host-key prompts. Automexia does not silently reconnect. - You want a clean start: choose Start clean or set
startup-prompt = "never"and use manual restore when needed. A cancelled restore keeps its candidate for retry. - The original folder is missing: the restored profile may use its configured start folder. Verify the directory before running anything.
Editors in alternate screen, running jobs, environment variables, images, active hyperlinks, and remote process state do not resume. An explicitly closed tab and short-lived Undo Close history are not recovery records.
If the earlier session came from a named profile, recovery does not replay its custom program arguments or reconnect a remote host. Start a new session with that profile when you need its exact launch recipe again.
Configure what is saved#
Use config.toml only when the defaults do not fit your workflow:
[session-recovery]
enabled = true
startup-prompt = "smart" # also "always" or "never"
save-history = true
excluded-profiles = ["wsl:Example"]save-history = false saves layout without new terminal text. enabled = false stops new saves and offers, but does not by itself delete an existing private checkpoint. Exclude a profile if its terminal output should not be captured; do not use the setting as a substitute for keeping secrets out of commands and logs.
Privacy and failure behavior#
Terminal history can contain sensitive data. The source encrypts recovery checkpoints for the local user using DPAPI on Windows, an unlocked Secret Service on Linux/BSD, or a Keychain-protected key on macOS. If protection is unavailable, it does not save plaintext as a fallback. Protect the state directory anyway; these snapshots are not portable backups.
Saves are coalesced, so a sudden crash can lose the latest moments. Disk or protection errors preserve the last valid checkpoint where possible. A failed restore does not mark its candidate as consumed. If a profile or WSL distribution cannot start, other available sessions can still reopen. For normal preference changes rather than workspace recovery, see Customization.