Skip to content
doubtbuddy.ai
Start with the workflow

Let’s make the first useful milestone concrete.

Bring the systems, constraints, and workflow you want to improve. We’ll map the smallest credible path to production.

DOUBTBUDDY JOURNAL

Your SSH Session Isn't Dying Because of Your Internet

I blamed my Wi‑Fi for a week. The real culprit was where my work was living — and one tool moved it somewhere safe.

2 views
Cover

For a week I blamed my Wi‑Fi.

I'd be deep in a terminal session on a remote server — a long‑running job going, an AI coding agent mid‑task — and the connection would drop. Back in, restart, lose my place. Again. My internet was fine. The server was fine. So what kept kicking me out?

It turned out I'd misdiagnosed the whole thing. Here's what was actually happening, and the one change that fixed it for good.

The wrong suspect

The obvious theory is "bad connection." But when I actually looked, two things were true at once:

- My home internet was stable.
- The server was healthy — 85 days of uptime, plenty of free memory, no crashes.
The disconnect notices were coming from somewhere in between. Some were cosmetic — background services reconnecting and printing noisy "disconnected / reconnected" messages that looked alarming but changed nothing. The real damage was different: every so often the SSH link itself would quietly time out, and whatever I had running died with it.

That last part is the key, and it's not a bug. It's how SSH works by default.
Who actually "owns" your program?
When you SSH into a server and run something, that something isn't floating freely on the machine. It's a child of your SSH session. You can see this by tracing a process's family tree. On a plain SSH shell, it ends like this:

bash  →  your-program  →  sshd

sshd — the SSH daemon — is the ancestor. So the moment the SSH connection goes away, the server sends a "hang up" signal down that chain, and your program goes with it. Your work was never living on the server independently; it was living on the connection. Break the connection, lose the work.
That's the real reason "my internet dropped for two seconds" costs you a whole session.
The fix: give your work a home on the server
The tool for this is tmux (a "terminal multiplexer"). The idea is simple: instead of running your program directly under SSH, you run it inside tmux, and tmux runs as its own long‑lived process on the server. SSH just becomes a window looking in.

After switching, the same family tree looks like this:

bash  →  your-program  →  bash  →  tmux: server

Notice what's at the top now: tmux: server, not sshd. Your program belongs to tmux, and tmux belongs to the server itself. When SSH drops, only your view disconnects — the program keeps running. You reconnect and "reattach," and you're exactly where you left off.

The analogy that made it click for me: a plain SSH shell is a phone call — hang up and it's over. tmux is a recording that keeps playing on the server — you can walk away, come back, and rejoin it still running.

Setting it up

Three small steps, in order of impact:

1. Use tmux (the big one).

tmux new -s work      # start a named session, then run your stuff inside
# if you get dropped:
tmux attach -t work   # back exactly where you were
Detach on purpose with Ctrl‑b then d. List sessions with tmux ls.

2. Make it automatic. So you never forget, wrap your command in your ~/.bashrc so it always launches inside tmux — re‑attaching if a session already exists, creating one if not. Then you just type the command as usual and tmux happens invisibly.

3. Add SSH keepalives on your local machine, in ~/.ssh/config, so idle connections don't get cut in the first place:

Host my-server
ServerAliveInterval 30    
ServerAliveCountMax 6  
TCPKeepAlive yes

This pings the server every 30 seconds to keep the tunnel from going idle.
The honest caveats: tmux is a safety net, not magic:

- It survives disconnects, not a server reboot. If the machine itself restarts, the session is gone. (Rare on a long‑lived server, but real.)

- The "plain shell dies on disconnect" behavior is the default. There are other ways around it (nohup, disown, screen), but tmux is the one worth learning because it also gives you persistent, reattachable workspaces.

The takeaway - If a remote session keeps dying and your internet is fine, stop blaming the network. Ask a better question: where does my work actually live? By default, it lives on a fragile link between your laptop and the server. Move it onto the server with tmux, and a dropped connection becomes a shrug instead of a restart.

One green status bar at the bottom of the screen, and I stopped losing work.

2 views