Keep remote jobs running after your Mac sleeps or SSH disconnects

Start a long job inside tmux on the remote server before you disconnect. When your Mac wakes, reconnect to the same server with the same remote user and reattach to that session. Reconnecting an SSH client restores access; it does not by itself recover the old shell or restart an interrupted job.

This workflow is for a build, export, backup or interactive maintenance task running on a Linux server. It works from Apple Terminal or an SSH terminal in Nexus Shell. It does not require Agent Bridge or a Pro upgrade for tmux itself.

Choose what needs to survive

• An interactive server job: use remote tmux, then reattach. Check that the process is still running before starting another copy.
• A scheduled job or service that must recover after a server reboot: use the server's service manager or job scheduler, with application-specific restart and checkpoint rules. tmux alone is not a reboot strategy.
• A file transfer between your Mac and the server: remote tmux cannot keep the Mac's transfer process or network running. Check the transfer result and the client's documented resume support.
• A local SSH tunnel to a database: recreate the forwarding connection after a disconnect, then reconnect the database client. Use the local tunnel command builder to check which machine each address belongs to.

1. Create the session on the server

Connect to the intended server. In that remote terminal, check the hostname, user and whether tmux is installed:

hostname
id -un
command -v tmux
tmux -V

If tmux is missing, arrange installation on that server using its supported package manager and your normal permissions. Installing tmux on your Mac alone does not protect a job on another machine. See the tmux installation documentation.

Create a named session before starting the real work:

tmux new-session -s maintenance

If that name already exists, inspect it with the commands in step 3; do not create a second copy of a backup or deployment just because the client disconnected. A tmux status bar normally appears at the bottom, but configurations can change its appearance.

2. Rehearse with a harmless one-minute counter

Inside the tmux session, paste this counter. It only prints numbered lines and UTC timestamps to the terminal; it does not modify files, install software or contact another host.

i=0
while [ "$i" -lt 30 ]; do
  i=$((i + 1))
  printf 'tick %s/30 ' "$i"
  date -u '+%H:%M:%S UTC'
  sleep 2
done
printf 'rehearsal finished\n'

Press Ctrl-B, release both keys, then press D. These are tmux's default detach keys. You should return to the outer remote shell while the counter continues inside tmux. You can now close this test SSH connection and reconnect; you do not need to put your Mac to sleep to rehearse the recovery step.

The shell counter is intentionally separate from a real workload. Passing it checks your session workflow, not the success or restart safety of a backup, migration or deployment.

3. Reconnect and inspect before resuming

Reconnect to the same host and remote account. List the sessions, then attach to the one you created:

hostname
id -un
tmux list-sessions
tmux has-session -t '=maintenance'

Confirm the host and user first. If has-session reports an error, stop and inspect the session list. If those checks pass, return to that exact session:

tmux attach-session -t '=maintenance'

The counter should have advanced or display “rehearsal finished”. A fresh shell prompt from your SSH app alone is not evidence that the old job survived. Once the rehearsal has finished, run your real task inside the attached session and keep its normal application logs and exit status.

For a real task, a visible error, nonzero exit status or incomplete output needs investigation even if tmux is still running. A successful backup also needs the tool's integrity or restore check; terminal scrollback is not a backup verification system.

When all work in this test session has finished, type exit in its shell. This closes that shell; if it is the last pane/window, the session ends. Do not use a blanket kill-server command to tidy up: it would terminate other tmux sessions for the same server instance.

Build the return command for an existing session

Use your existing session's exact name, not the name of a new job. tmux accepts prefixes and patterns as targets unless the name starts with an equals sign. For example, backup can match backup-old; '=backup' requires the session named backup. The return tool uses exact targets and keeps inspection separate from the return command.

Already inside tmux on the same server? Switch the current client instead of nesting another tmux client:

tmux switch-client -t '=maintenance'

If another terminal is attached, coordinate before typing. These commands do not force it off. A session that disappeared between the checks and the return command needs investigation; the tool cannot restore it or start a replacement job.

For a video conversion, a large export or a backup, inspect the original output and application logs after returning. A continuously running stream or service that must recover after a reboot needs a service manager and application-specific recovery rules. tmux alone does not supply those rules.

If the old session is missing

• Wrong host or user: compare hostname and account with step 1. Sessions belong to the remote account that started them; connecting as another user does not show the same list.
• “No server running” or “no sessions”: check whether the server rebooted, the session exited, or the administrator's logout policy terminated user processes. tmux is not a guarantee against those events.
• A session is already attached: another terminal may be viewing it. Reattaching can share that session; coordinate before typing. Avoid forcing other clients off as a default fix.
• The original command was launched outside tmux: starting tmux now does not automatically adopt that running command. Inspect the existing process and logs before considering a restart. Retrying a deployment or migration can have side effects.

Keepalive, Mac sleep and remote jobs are different problems

SSH keepalive messages can help detect an unresponsive connection, and may prevent some idle network timeouts. They cannot make an unavailable network carry traffic. In OpenSSH, ServerAliveInterval and ServerAliveCountMax control client checks; those settings are not instructions to restart a remote process. See the OpenSSH client configuration manual.

Keeping a Mac awake can help a local transfer while its network remains available, but it is not a substitute for a server-side session. A sleeping or disconnected Mac cannot be relied on to maintain a local forward or SFTP transfer. For persistent services, follow the server's service-management policy instead of leaving a terminal open indefinitely.

SSH still disconnects with keepalive enabled

Keepalive checks whether the SSH peer responds; it does not prove that a shell is accepting input or that a job is running. A shell idle timer, an inactive-channel policy, a broken network and Mac sleep require different evidence. Record the disconnect time and exact message before changing settings or starting another copy of the job.

• Mac slept or changed networks: compare the time with the Mac's power/network events. Keepalive cannot carry traffic through a missing connection. Reconnect, then inspect the existing remote task.
• The terminal prints auto-logout or timed out waiting for input: inspect the remote shell's idle policy. In Bash, TMOUT applies while waiting at its prompt; it is not a measurement of SSH peer responsiveness.
• A shell, quiet command or tunnel closes at a repeatable interval while the peer stays reachable: ask the administrator to inspect channel-idle and gateway policies. A repeating interval is a clue, not proof of one cause.
• Output was still arriving when the connection froze: compare same-time client/server and VPN/router evidence. Do not assume an idle-only problem or disable the firewall to test it.

Check the client, then the remote shell

In Terminal on the Mac, inspect the evaluated OpenSSH settings for your trusted host alias:

ssh -G your-saved-host

Find serveraliveinterval, serveralivecountmax, controlmaster, controlpath and, where supported, channeltimeout. This prints configuration rather than connecting. Trusted Match exec rules can still run local commands; do not evaluate an untrusted config or publish the full output. Existing multiplexed connections can use an older master's settings. Nexus Shell's saved-connection behavior is separate; this does not establish that an app imported the OpenSSH options.

In the remote terminal, first confirm the shell with the administrator. For a Bash session, these commands inspect its version and timer without changing them:

printf 'Bash: %s\n' "${BASH_VERSION-not Bash}"
printf 'TMOUT: %s\n' "${TMOUT-unset}"

An unset Bash timer rules out that one variable in that shell, not every server timeout. Check the outer login shell and the intended tmux pane separately. A tmux server can remain alive after its shell exits; a session name alone does not prove the old process survived. Follow the GNU Bash interactive-shell reference. Respect an intentional logout policy rather than removing it as a default fix.

Channel inactivity is different from an unresponsive peer

On OpenSSH versions that support ChannelTimeout, client or server policy can expire an inactive session channel. Transport keepalive responses do not establish that the shell channel carried activity. Check the installed versions and effective settings with the administrator; conditional Match rules matter. ClientAliveInterval and ClientAliveCountMax test peer responsiveness, not whether someone is typing.

Closing a channel does not guarantee that its associated processes stopped, or that the whole SSH connection closed. Verify the original job before retrying. See the official client channel policy and server channel policy; do not change production timeouts solely from an error string.

Our local Bash idle-timeout rehearsal uses two isolated pseudo-terminals without SSH or user startup files. With a two-second timer, the idle prompt logged out; a three-second foreground command finished, then the returned prompt logged out. This demonstrates shell behavior, not a network outage, server-policy compatibility or Nexus Shell reconnection. Use the tmux steps above to inspect the original task after reconnecting.

Where Nexus Shell fits

Use a saved connection in Nexus Shell to open the server terminal, start tmux there, and return to that saved host after a disconnect. Nexus Shell's reconnection behavior does not promise to restore a remote process or automatically attach your tmux session. Run the attach command explicitly and verify the result.

If your next task is inspecting logs as files, use the SFTP workflow. For a container that is running but failing its application task, inspect Docker state, bounded logs and host resources. SFTP, Docker management and monitoring are Pro features; personal, non-commercial SSH use has a free tier. Nexus Shell requires Apple Silicon and macOS 14.2+.

The website edition offers lifetime Pro only. Prefer Apple billing or an annual subscription? Review the secondary App Store purchase options. The App Store edition has lifetime and auto-renewing annual options, no Nexus Shell account and no Agent Bridge. Channel purchases and data are separate; connections do not migrate automatically. See the current terms before choosing a channel.

Sources and verification scope

Published September 26, 2026. In an isolated local macOS pseudo-terminal test with tmux 3.7c, we detached and reattached clients while the counter ran. The same pane process remained, the counter advanced from tick 1 to tick 2 across the detach, and all 30 ticks finished. The test used its own socket and did not load the user's tmux configuration.

Read the test result and reproduction instructions. This tests local tmux continuity, not an SSH outage, a customer's server, the recovery behavior of a real application or a physical Mac sleep cycle.

The remote workflow follows the tmux Getting Started guide and command manual.