PuTTY Inactive: How to Fix It

What you're seeing

The PuTTY window title changes to something like:

user@server: ~ (inactive)

Typing does nothing, and the window may have shown a fatal error dialog first, or simply gone quiet. "Inactive" is PuTTY's label for a session that has ended, whatever ended it. The window stays open so you can read the final output.

To reconnect without setting anything up again, right-click the title bar (or the PuTTY icon in the top-left corner of the window) and choose Restart Session. That's the whole answer to "how do I activate an inactive PuTTY session". The interesting question is why it keeps going inactive.

What's causing it

The session ended, and something ended it. The usual suspects, in rough order of frequency:

1. An idle timeout in the network path. A NAT router, firewall, or VPN dropped the TCP connection after 5 to 15 minutes of you not typing. This is the cause when the window goes inactive after a consistent idle period and usually pairs with a Software caused connection abort dialog.
2. The server closed the session. sshd restarted during an upgrade, the machine rebooted, or sshd_config's ClientAliveCountMax gave up on an unresponsive client.
3. A shell auto-logout on the server. If the TMOUT variable is set, bash exits after that many idle seconds and logs you out cleanly. The tell: the window prints logout or timed out waiting for input before going inactive, with no network error dialog.
4. Your network changed. Laptop sleep, Wi-Fi roaming, dock/undock, VPN reconnect. The old connection can't survive a new source address.
5. You typed exit or pressed Ctrl+D. Not a joke; with "Close window on exit" set to Never, a normal logout also leaves an inactive window.

How to fix it

Turn on keepalives

The fix for cause 1, which is most cases. In PuTTY: load your session, go to Connection, set Seconds between keepalives (0 to turn off) to 30, tick Enable TCP keepalives, then go back to Session and Save. The Software Caused Connection Abort guide is the deeper dive, including the server-side ClientAliveInterval setting and running long jobs in tmux so a drop can't kill them.

Check for TMOUT on the server

If the session ends with a clean logout rather than a network error, look for an auto-logout policy:

echo $TMOUT

Empty means it's not the cause. A number is the idle limit in seconds. It's usually set in /etc/profile or a file under /etc/profile.d/; find it with:

grep -r TMOUT /etc/profile /etc/profile.d/ 2>/dev/null

For your own account, unset TMOUT in the current shell, or add it to ~/.bashrc. If the admin made it readonly, unsetting fails; that's a deliberate security policy, so keepalives won't help either. Work with it, or take it up with the admin.

Keep the window open long enough to read the error

If PuTTY windows vanish before you can see what happened, set Session panel → Close window on exit → Never (and Save). The window then always stays open, inactive, with the last output and any error dialog visible. That error text tells you which cause you're dealing with; if it's a network error at connect time, start from Connection refused or Connection timed out instead.

Common edge cases