Documentation

Guides, tutorials, and frequently asked questions

Keep an SSH Session Alive When the Wi-Fi Drops | YoloShell

Frequently asked questions

What happens to my SSH session when Wi-Fi drops?
With Mosh roaming the session stays alive and resumes on the new network — Wi-Fi to 5G, a tunnel, or anywhere else your IP changes. A plain SSH connection would drop and need reconnecting.
Does YoloShell support both SSH and Mosh?
Yes. SSH, Mosh and tmux are all in one client, with per-profile Mosh and tmux settings.
Can I keep the session across a tunnel switch?
That is what Mosh roaming is for — the session survives the network changing underneath it, rather than being bound to one connection.
Where are my connection settings and keys stored?
On device. SSH keys are generated or imported into the iOS Keychain, and connection config stays local, with no telemetry of shell content and no host-name logging.
Does Mosh work on any server?
No. Mosh needs UDP egress and a Mosh-enabled remote server. A host that only allows TCP port 22, or one without the Mosh server installed, cannot roam at all — no client-side setting fixes that.
Does YoloShell need to stay in the foreground to keep a session alive?
Backgrounding iOS is what silently kills a mobile terminal. YoloShell uses location permission solely to sustain background execution and prevent disconnections, and your location is not uploaded.

The short answer

A plain SSH session is a TCP connection stamped with your phone's current IP address. Change networks and that address is gone, so the connection is gone — and with it the shell, the running build, the half-finished git rebase, and the tmux server you were attached to.

Mosh roaming keeps that session alive across Wi-Fi, 5G and tunnel switches. Your shell keeps running on the remote machine while your phone's network changes underneath it, and the terminal catches up where you left off. YoloShell ships SSH, Mosh and tmux in one iPhone and iPad client, with Mosh, tmux and on-open scripts configured per host.

Two limits are worth knowing before anything else, because both cause the "it says it roams but mine drops anyway" experience: Mosh needs UDP egress and a Mosh-enabled remote server, and iOS will still cut a backgrounded app loose unless you grant location permission.

Why a network change is worse than losing signal

These two feel the same when you are walking out of a room, and they are not.

Lose signal for ten seconds inside the same Wi-Fi and the TCP connection usually survives, because your IP address has not changed — the stack simply retransmits until the packets get through. Switch from Wi-Fi to 5G, walk outside and back through a VPN, or re-associate with a different access point in the same building, and your source address changes. The old address is unreachable, so nothing retransmits its way out. The network closed the connection, not your terminal.

That is why a reconnect button is not a solution. Reconnecting gives you a new shell. Whatever was in the first one — editor state, a make that was ninety percent done, the tmux server you had attached to — does not come with it.

What Mosh roaming actually changes

The difference is where the session lives.

  • Over SSH, the session lives in the TCP connection. The connection is the session.
  • Over Mosh, the session lives in a process on the remote machine. Your phone holds a datagram link to it, and when the network changes the client comes back over the new address and reattaches to the same running shell.

Concretely: work in the shell, walk out of Wi-Fi range, come back on 5G, and the cursor is where you left it with the scrollback intact. The tunnel case is the one that surprises people most, because a VPN or a jump host changes the path on every reconnect — which is exactly the "tunnel switches" case YoloShell's own documentation calls out as supported.

Underneath it is UDP rather than TCP. That is a genuine trade: a datagram transport that tolerates a gap and predicts the next keystroke is what makes coming back after a gap possible at all, and it is also why the requirement below exists.

What Mosh needs on the other end

Mosh requires UDP egress and a Mosh-enabled remote server. Both are server-side or network-side facts, and neither is fixable from the phone:

  • The host must have the Mosh server package installed and reachable over UDP. A minimal container image, or a locked-down VPS whose security group opens only TCP 22, cannot roam no matter how the profile is configured.
  • The network must let UDP through. Corporate Wi-Fi and school networks that filter UDP, hotel and airport captive portals, and any egress list that reads "TCP 22 only" are exactly the cases people hit most. Plain SSH still works there — roaming does not, because it was never a client setting.

YoloShell's Mosh settings are per-profile, so this is a per-host decision: the box that has Mosh installed and the box behind a bastion that does not can both live in the same app, configured differently, instead of needing a second terminal client.

tmux is the other half, and it is not the same thing

tmux runs on the server. Your shell dies; the tmux server does not. So a drop Mosh cannot cover still leaves your panes intact, and reattaching gives you the same windows back.

YoloShell drives tmux in control mode (-CC), which gives a native tab and pane UI rather than tmux's text rendering over SSH. That part is a Pro feature and it has its own page — tmux panes and tabs on an iPad covers the UI, the iPad multi-tab layout and live OSC-synchronised tab titles.

The honest way to hold the two: tmux protects the work when the link dies; Mosh keeps the link from dying when the network changes. Used together, most network events cost you nothing at all. Used alone, each leaves a gap — tmux gives you your session back only if you remember to reattach, and Mosh gives it back only if the remote can speak Mosh in the first place.

The disconnect that is not about your network

The other way a mobile terminal dies has nothing to do with Wi-Fi: iOS suspends a backgrounded app. A suspended process stops reading its socket, and the remote eventually reaps the session.

YoloShell's privacy policy is explicit about how it handles this: when you grant location permission, it is used solely to sustain background execution and prevent disconnections, and your location is not uploaded. That is the entire purpose of the prompt. If you denied it or turned it off later, a roaming session will survive the network change but may not survive you switching to another app — which is worth knowing before concluding that roaming is broken.

The rest of the privacy posture matters for a tool that holds your keys: all connection configuration and SSH keys stay on device, keys in the iOS Keychain and profiles in a sandboxed file, with no telemetry of shell content, no remote logging of host names, and no account. Anonymous analytics are on by default and there is currently no in-app toggle — to opt out you contact support and collection is disabled for that installation.

What roaming costs in YoloShell terms

The free tier keeps one concurrent session on any device, three hosts and two SSH keys. That one -session limit applies on iPhone too, not only on iPad, which matters here: a roaming setup is usually more than one host — the box you sit at and the one you jump through — and the free tier does not cover two live sessions at once.

YoloShell Pro raises that to multiple concurrent sessions, unlimited hosts and SSH keys, tmux control mode (-CC), three extra terminal palettes (Solarized Light, Dracula and Nord) on top of the two that ship free (Default and Solarized Dark), and priority support. Font size, family and cursor styling are free for everyone. Pro is $2.99/month or $14.99/year at the US list price — regional pricing differs and the app shows the live price — with a 7-day free trial on the yearly plan for new subscribers only; the monthly plan has no introductory offer.

The app requires iOS 17 or later.

What YoloShell does differently

  • Three protocols, one client, configured per host. SSH, Mosh and tmux live in the same app with per-profile Mosh, tmux and on-open scripts, instead of a roaming-capable box and a locked-down one pushing you toward two different terminal apps.
  • A native iOS client, not a wrapper. Full xterm-256color, true colour and Unicode, iPad multi-tab terminals with live titles synced from OSC sequences, and VNC remote desktop built in and free — with touch gestures and a full hardware-style key bar — for when the thing you need is a desktop rather than a shell.
  • Keys that stay on device. Generated or imported into the iOS Keychain, profiles in a sandboxed file, no shell-content telemetry, no host-name logging, no account required.

The honest limits: YoloShell cannot make a UDP-blocked network work, cannot rescue a host without the Mosh server installed, and cannot stop iOS from suspending the app if you decline location permission. And it ships no AI service — Herdr agents such as Claude Code or Codex run on the remote machine and must already be installed there, as the coding agent page explains.

What to do next

If your sessions die when you switch networks — the one failure a mobile terminal has and a desktop terminal does not — the fix is not a reconnect button. It is Mosh on the hosts that can speak Mosh, tmux on the hosts that cannot, location permission granted so iOS does not suspend the app, and Pro if you need more than one session alive at a time.

The single check that decides which half you need: does your remote host have the Mosh server installed, and does your network allow UDP? If either answer is no, you are in the tmux half, and that is a fine answer — it just protects the work rather than the connection.

YoloShell is on the App Store if you want to try it against a host you control before deciding.