HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
mobile-shell
mosh
C++2012–2026
mobile-shell / mosh

mosh

Mobile Shell

64Distinct people
84Mentions
3Explicit recommenders
14.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Mobile Shell

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

If you use a combo of iTerm on Mac + Mosh + tmux, I highly recommend rebuilding mosh on client/server from this PR[1] which adds better support for copy & paste. Also, if you…

turdnagel used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year84 dated mentions

Observed mentions: 2012-04-02 12:36:39 UTC to 2026-10-14 06:20:46 UTC.

0510152012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20122013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 6 mentions; 3 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 13 mentions; 0 submissions, 13 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC514
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC817
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC413
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC633
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC13013
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC606
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC505
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC13013
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC615
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC606
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC404

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Mosh: the mobile shell Mosh is a remote terminal application that supports intermittent connectivity, allows roaming, and provides speculative local echo and line editing of user keystrokes. It aims to support the typical interactive uses of SSH, plus: Mosh keeps the session alive if the client goes to sleep and wakes up later, or temporarily loses its Internet connection. Mosh allows the client and server to "roam" and change IP addresses, while keeping the connection alive. Unlike SSH, Mosh can be used while switching between Wi-Fi networks or from Wi-Fi to cellular data to wired Ethernet. The Mosh client runs a predictive model of the server's behavior in the background and tries to guess intelligently how each keystroke will affect the screen state. When it is confident in its predictions, it will show them to the user while waiting for confirmation from the server. Most typing and uses of the left- and right-arrow keys can be echoed immediately. As a result, Mosh is usable on high-latency links, e.g. on a cellular data connection or spotty Wi-Fi. In distinction from previous attempts at local echo modes in other protocols, Mosh works properly with full-screen applications such as emacs, vi, alpine, and irssi, and automatically recovers from occasional prediction errors within an RTT. On high-latency links, Mosh underlines its predictions while they are outstanding and removes the underline when they are confirmed by the server. Mosh does not support X forwarding or the non-interactive uses of SSH, including port forwarding. Other features Mosh adjusts its frame rate so as not to fill up network queues on slow links, so "Control-C" always works within an RTT to halt a runaway process. Mosh warns the user when it has not heard from the server in a while. Mosh supports lossy links that lose a significant fraction of their packets. Mosh handles some Unicode edge cases better than SSH and existing terminal emulators by themselves, but requires a UTF-8 environment to run. Mosh leverages SSH to set up the connection and authenticate users. Mosh does not contain any privileged (root) code. Getting Mosh The Mosh web site has information about packages for many operating systems, as well as instructions for building from source. Note that mosh-client receives an AES session key as an environment variable. If you are porting Mosh to a new operating system, please make sure that a running process's environment variables are not readable by other users. We have confirmed that this is the case on GNU/Linux, OS X, and FreeBSD. Usage The mosh-client binary must exist on the user's machine, and the mosh-server binary on the remote host. The user runs: $ mosh [user@]host If the mosh-client or mosh-server binaries live outside the user's $PATH, mosh accepts the arguments --client=PATH and --server=PATH to select alternate locations. More options are documented in the mosh(1) manual page. There are more examples and a FAQ on the Mosh web site. How it works The mosh program will SSH to user@host to establish the connection. SSH may prompt the user for a password or use public-key authentication to log in. From this point, mosh runs the mosh-server process (as the user) on the server machine. The server process listens on a high UDP port and sends its port number and an AES-128 secret key back to the client over SSH. The SSH connection is then shut down and the terminal session begins over UDP. If the client changes IP addresses, the server will begin sending to the client on the new IP address within a few seconds. To function, Mosh requires UDP datagrams to be passed between client and server. By default, mosh uses a port number between 60000 and 61000, but the user can select a particular port with the -p option. Please note that the -p option has no effect on the port used by SSH. Advice to distributors A note on compiler flags: Mosh is security-sensitive code. When making automated builds for a binary package, we recommend passing the option --enable-compile-warnings=error to ./configure. On GNU/Linux with g++ or clang++, the package should compile cleanly with -Werror. Please report a bug if it doesn't. Where available, Mosh builds with a variety of binary hardening flags such as -fstack-protector-all, -D_FORTIFY_SOURCE=2, etc. These provide proactive security against the possibility of a memory corruption bug in Mosh or one of the libraries it uses. For a full list of flags, search for HARDEN in configure.ac. The configure script detects which flags are supported by your compiler, and enables them automatically. To disable this detection, pass --disable-hardening to ./configure. Please report a bug if you have trouble with the default settings; we would like as many users as possible to be running a configuration as secure as possible. Mosh ships with a default optimization setting of -O2. Some distributors have asked about changing this to -Os (which causes a compiler to prefer space optimizations to time optimizations). We have benchmarked with the included src/examples/benchmark program to test this. The results are that -O2 is 40% faster than -Os with g++ 4.6 on GNU/Linux, and 16% faster than -Os with clang++ 3.1 on Mac OS X. In both cases, -Os did produce a smaller binary (by up to 40%, saving almost 200 kilobytes on disk). While Mosh is not especially CPU intensive and mostly sits idle when the user is not typing, we think the results suggest that -O2 (the default) is preferable. Our Debian and Fedora packaging presents Mosh as a single package. Mosh has a Perl dependency that is only required for client use. For some platforms, it may make sense to have separate mosh-server and mosh-client packages to allow mosh-server usage without Perl. Notes for developers To start contributing to Mosh, install the following dependencies: Debian, Windows Subsystem for Linux: $ sudo apt install -y build-essential protobuf-compiler \ libprotobuf-dev pkg-config libutempter-d
Read the full README on GitHub

What Hacker News says

84 sources
The chat I mentioned above linked this issue, which, to be honest, I skimmed and said, ok, yeah, Astra's right, ControlMaster seems maybe like a big no go, then never tried. https://github.com/mobile-shell/mosh/issues/24 I tend to have ~20+ tabs open and each one has it's own tmux session inside of it, with multiple windows. I do think that making a terminal that can script and control multiple tmux sessions via control mode is, sort of, the longer destination ahead for me! That'll be exciting.
In Show HN: Mosh-rs, Mosh rewritten in Rust with scrollback and Windows support
mosh is neat, but I've mostly switched back to good'ol SSH over Tailscale due to various rendering bugs caused by client-server mismatches as well as the lack of port forwarding. Basically mosh attempts to synchronize the state of the terminal which is made up of character cells. It sounds simple until you realize that unicode and fancy escape sequences exist, and the behavior of the client and the server must match otherwise you get weird misalignments that are difficult to debug: - Unicode 9+ changed character width computation a lot, but macOS `wcwidth` still follows the old algorithm. Let's patch it: https://github.com/mobile-shell/mosh/pull/1289 - There is no support for strike-through and dimmed styles. Let's patch it: https://github.com/mobile-shell/mosh/pull/1059 - What about underline/undercurl? Let's patch it: https://github.com
Read the rest
/jdrouhard/mosh/commit/aff5e1c3db9f061deb2... - Some emojis don't take up two cells as expected? Again, let's patch it: https://github.com/jdrouhard/mosh/commit/b31161ab311c7b6e306... - ... You really need those patches to have a good experience, and popular mosh clients like Blink on iOS incorporate them in their builds. However, things look wonky if you don't use the corresponding server builds, and you don't want to dig through layers of abstractions to find out why selecting lines in a specific file in neovim causes everything to become a jumbled mess every so often. There is no end in sight for those patched to be merged upstream, no end in sight for distros to ship new versions, and no end in sight for protocol changes to make state synchronization more resilient. So, back to SSH we go... Edit: Fixed wrong link for underline/undercurl patch
In Mosh Mobile Shell
Another alternative is running ssh over Wireguard. It gives you some of the same benefits, like roaming between different internet connections while transparently maintaining connections that are going through the Wireguard VPN connection. https://www.wireguard.com/ I used to use mosh, but the lack of support for scrollback in mosh eventually made me give up on it. https://github.com/mobile-shell/mosh/issues/122 I’ve been happy running ssh over Wireguard instead. Not just as a replacement for mosh but also because I wanted my own VPN in the first place. I use the VPN for connections between my own computers. I don’t bother routing traffic for the wider internet through my VPN although Wireguard can do that too if you want.
In Run VSCode and terminal on any iOS device
FWIW, I wouldn't try to parse escape sequences directly from the input bytestream -- it's easy to end up with annoying edge cases. :-/ In my experience you'll thank yourself if you can separate the logic into something like: - First step (for a UTF-8-input terminal) is interpreting the input bytestream as UTF-8 and "lexing" into a stream of Unicode Scalar Values (https://www.unicode.org/versions/Unicode15.1.0/ch03.pdf#P.12... ; https://github.com/mobile-shell/mosh/blob/master/src/termina...). - Second step is "parsing" the scalar values by running them through the DEC parser/state machine. This is independent of the escape sequences (https://vt100.net/emu/dec_ansi_parser ; https://github.com/mobile-shell/mosh/blob/master/src/termina...). - And then the third step is for the terminal to execute the dispatch/execute/etc. actions coming from
Read the rest
the parser, which is where the escape sequences and control chars get implemented (https://www.vt100.net/docs/vt220-rm/ ; https://invisible-island.net/xterm/ctlseqs/ctlseqs.html ; https://github.com/mobile-shell/mosh/blob/master/src/termina...). Without this separation, it's easier to end up with bugs where, e.g., a UTF-8 sequence or an ANSI escape sequence is treated differently if it's split between read() calls (https://bugs.chromium.org/p/chromium/issues/detail?id=212702), or invalid input isn't correctly recovered-from, etc.
In Write your own terminal

Showing the 15 most recent of 84 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.