When mosh-server cannot be found v26.1.0+

A mosh connection is two steps. Term signs in over SSH, and over that connection it runs mosh-server on the host; the server prints a port and a key, and only then does the UDP session start.

So this error is precise about which step failed: SSH succeeded. The address, the port, the username and your key or password are all correct — the host simply could not run mosh-server. The detail line underneath says the same thing in the app’s own words: ServerNotFound.

There are only two reasons for it. Either mosh is not installed on that host — in which case install it and you are done — or it is installed and the host cannot find it. The rest of this page is about the second one, which is by far the more confusing of the two, because mosh works perfectly when you type it yourself.

Log into the host and run mosh-server by hand and it runs. So why can’t Term?

Because they are not the same kind of session. When you log in, your shell reads its startup files — .profile, .bashrc, .zshrc — and those are where a package manager adds its directory to PATH. Term does not open a login shell to start mosh; it runs a single command over SSH, the equivalent of ssh you@host mosh-server. That is a non-interactive session, and it gets the PATH sshd hands out, typically just:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

If mosh-server lives anywhere else, it is invisible to that command — while remaining perfectly visible to you.

This also explains why the same setup works for one person and not the next: zsh reads .zshenv even non-interactively, so a PATH set there survives, while bash reads neither .bashrc nor .profile for a non-interactive command. Same host, same install, different shell, different outcome.

Two commands from your computer. The first asks the host the same way Term does, and confirms the diagnosis — it should print nothing:

# what Term sees: no output = the PATH problem this page is about
ssh you@host 'command -v mosh-server'

# what you see: a login shell finds it
ssh you@host 'bash -lc "command -v mosh-server"'

The second command runs through a login shell, which is what you get when you sign in normally. If the first prints nothing and the second prints a path, that path is your answer — copy it exactly.

If both print nothing, mosh is genuinely not installed on that host. Install it with the host’s package manager and nothing else on this page applies.

If you would rather just try the likely paths, these are the ones that account for nearly every case. The rule underneath is always the same: a package manager that installs outside /usr/bin puts its directory on PATH from a shell startup file, and a non-interactive command never reads it.

A ~ works here: the host expands it, because the command still runs through a shell on the far end. If you would rather be literal, write the full path — /home/you/bin/mosh-server.

Open the host — Edit host on the failure screen goes straight there — and find Connection. With the transport set to Mosh, under the UDP port field, there is mosh-server command (optional). Leave it blank on every host where mosh installed normally; this is the one place it earns its keep.

It is a command, not merely a path, and Term passes it through untouched — the same thing mosh’s own --server option takes. So sudo mosh-server works, and so does a wrapper script of your own that sets something up before exec’ing the real binary.

References: Customizing mosh · FAQ — how to connect over mosh