# 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](https://nexusshell.app/en/tools/ssh-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:

```sh
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](https://github.com/tmux/tmux/wiki/Installing).

Create a named session before starting the real work:

```sh
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.

```sh
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:

```sh
hostname
id -un
tmux list-sessions
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.

## 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](https://man.openbsd.org/ssh_config#ServerAliveInterval).

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.

## 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](https://nexusshell.app/en/guides/edit-remote-file-macos-sftp/). For a container that is running but failing its application task, [inspect Docker state, bounded logs and host resources](https://nexusshell.app/en/guides/troubleshoot-remote-docker-from-mac/). 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](https://nexusshell.app/en/#download-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](https://github.com/viewer12/Nexus-Shell-Releases/blob/main/docs/remote-jobs.md#reproduce-the-local-continuity-check). 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](https://github.com/tmux/tmux/wiki/Getting-Started) and [command manual](https://man.openbsd.org/tmux).