Your terminal died 47 times this month. Did you notice?

Forty-seven is an estimate. Yours is countable: every editor quit, every reload after an extension update, every reboot the OS insisted on, every SSH drop, every actual crash. Each one closed a pseudo-terminal, and everything attached to it went too — the running build, four thousand lines of scrollback, the Claude Code session that was two files into a refactor. You stopped noticing because it happens too often to itemize.

What actually dies

A normal terminal lives inside the app that draws it. The emulator owns the PTY; your shell and everything it spawned hang off the other end. When the app exits — cleanly or not — the PTY closes, the kernel sends SIGHUP down the process tree, and the tree obliges. The scrollback doesn’t even get a signal: it was a buffer in the renderer’s memory, and the renderer is gone.

Then the second bill arrives. You restart, cd back to where you were, re-run the build, re-scroll for the error you were chasing, and re-explain to Claude what the two of you were doing. Call it twenty minutes. That’s the crash tax, and most of us have paid it so long it stopped showing up as a line item.

Where the session actually lives

ImmorTerm moves the session out of the blast radius. Every session is hosted by a daemon — a small persistent process that runs beneath the editor and owns the PTY, the process tree, and the full scrollback history. The terminal you look at is a client attached to that daemon. Quit the editor, crash it, reboot for a kernel update: you took down a view. The session wasn’t in the building.

This is continuity by architecture, not recovery after the fact. There’s no snapshot ritual, no save-session button, no resurrect script to maintain — nothing to babysit, because nothing is at risk.

The reattach mechanic

When you come back, the client finds its daemon, attaches, and replays. Three details do the heavy lifting:

• The process is the same process. Same PID, same working directory, same environment. The build that was fourteen minutes in is now however far it got while you were gone — it never heard about the crash.
• Scrollback replays at the width it was written. History is replayed cols-aware, resizes and all, so a session written at 200 columns doesn’t come back rewrapped into soup.
• Nothing is reconstructed. “Restore” implies a corpse and a backup. There is no backup, because there was no death — you reconnect to a process that kept running.

Isn’t this tmux?

tmux solved the process half of this decades ago, credit where due. But it makes you the mechanic: a prefix-chord vocabulary, a config file, a resurrect plugin you maintain, and a rendering model from another decade — where ImmorTerm renders on the GPU and stays smooth at thousands of lines. And a detachable process is only half the problem: tmux remembers nothing about what happened inside the session. Persistence without memory is a zombie.

The other half

A session that survives is half the organism. The same architecture carries an ambient memory that digests every session as it happens and recalls the relevant past in ~8ms, on-device, before you ask. That story is its own post: The memory that reads over Claude’s shoulder.

Try it

macOS and Linux, one package. Claude Code today, with the deepest integration.

local-first · free tier is real · nothing leaves your machine