Terminal sessions that survive disconnects

Everyone who works over SSH learns this one the hard way: you start a long job, the connection drops or the laptop lid closes, and the job dies with the session. Then someone introduces you to tmux, and from that day on you never run anything important outside it.

I used tmux daily for about ten years and I'm not here to dunk on it. But it's worth being honest about what it is: a fix for the fact that a terminal's lifetime is tied to a connection's lifetime. You run a terminal multiplexer inside your terminal, learn the prefix-key chords, and in exchange your sessions survive. The sessions surviving is the part you wanted; the rest is overhead you accepted to get it.

My terminals now live on the host machine as a built-in property of the setup, and the browser just renders them. This came as a side effect of moving my whole workflow to a browser workspace, and it's the feature I'd miss most if I moved back.

The model

The host machine (my VPS, or the desktop at home) runs:

npx codemote-cli start

and any browser pairs with it at the connect page. Terminals you open in the workspace are PTYs on the host. They belong to the host, not to the browser tab. Close the tab, kill the wifi, switch to a different computer: the shell process doesn't notice. Reconnect and the scrollback is there.

That's the entire pitch, honestly. The rest of this post is just evidence.

Things I've deliberately tested

Killed the wifi during an npm install: the install kept running on the host, the tab reconnected by itself, scrollback intact.

Closed the laptop overnight during a database migration: found the completed output in the morning. This used to be exactly the scenario where I'd discover at 9am that the migration had died at 11:03pm.

Opened the same workspace from two machines: same terminal on both, mirrored. It's one process on the host with multiple viewers, which is the tmux attach model without an attach step.

Do you still need tmux?

If your fingers want it, it still works; these are real PTYs, so tmux runs inside them the same as over SSH. For elaborate pane layouts or shared pair-debugging sessions it still earns its place.

What I noticed in my own usage: I stopped launching it. The two things I personally used tmux for were surviving disconnects and reattaching from another machine, and both come free now. Multiple terminals are just multiple terminals in the panel. Your reasons for tmux may be different from mine, in which case keep it; the two coexist fine.

Where this matters most for me now

Claude Code runs. An agent task can go for half an hour or more, and tying that to my laptop's network connection never made sense. On this setup the agent and the terminals are on the same always-on host, so I start a run, close everything, and check back later. That workflow has its own post.

Deploys and migrations, the jobs where dying halfway is worse than not starting. I don't run those over a bare SSH connection anymore, not because it usually fails but because I've lost that bet enough times that I'd rather not place it.

Limitations

The host has to stay awake; no software fixes a sleeping machine. And a terminal in a browser tab shares the keyboard with the browser, so a few shortcuts (Ctrl-W especially) go to the wrong place until your hands relearn. Those are the two real costs I've found in daily use.

The test that convinced me is easy to reproduce: start a build, close the laptop on purpose, come back in an hour. Beta signup is on the homepage.