Mosh Mobile Shell
Key topics
The mobile shell Mosh has been a lifesaver for many, but its two-year dormancy on master has sparked debate about its status - is it "complete" or has it been supplanted? Some users, like Kilenaitor, have moved on to Eternal Terminal, citing Mosh's limitations, such as lacking native scrollback, which requires workarounds like tmux. However, others point out that Eternal Terminal has its own drawbacks, like requiring a server process, highlighting the trade-offs between these tools. As users reminisce about Mosh's past usefulness and weigh its pros and cons, the discussion underscores the ongoing quest for a seamless, reliable remote shell experience.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
59m
Peak period
56
0-3h
Avg / period
9.8
Based on 78 loaded comments
Key moments
- 01Story posted
Aug 28, 2025 at 10:59 AM EDT
4 months ago
Step 01 - 02First comment
Aug 28, 2025 at 11:58 AM EDT
59m after posting
Step 02 - 03Peak activity
56 comments in 0-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Aug 30, 2025 at 4:13 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
But I don't know how widespread that is.
Mosh paints the screen, meaning no native scrollback. You have to use a multiplexer like tmux to get it. But ET has native scrollback. This is the biggest one for me.
Couple years ago I was on a more limited network that constrained usage of UDP which Mosh uses. ET uses TCP.
Mosh buffers inputs locally first which gives it the appearance of low latency but that illusion breaks when there are network issues. I prefer ET, even tho it can appear slower, since network issues are more obvious and I can troubleshoot them. But on a good connection, they're indistinguishable to me.
Those are three. There may be more. Honestly they are probably still more or less interchangeable for most. No reason to switch if you love Mosh.
Thanks for responding! :)
1. There was no scroll-back so you could only see 1 terminal screen of output. If you scrolled back, the text would be wrong or truncated or something like that. We would work around this by launching a tmux session and using that for scroll-back, but tmux scroll-back over a remote connection is so much clunkier than scrolling back in your local terminal emulator. If I'm already launching a tmux session, then I don't need mosh's ability to recover from broken connections because I can re-attach to tmux.
2. I found the typing prediction to be more annoying than it is worth. It worked great in bash but interactive apps (like those based on ncurses), the app would often end up a distorted mess until the round-trip to the server got back the real/correct rendering from the server. If I'm waiting for a round-trip from the server then I'm not getting any benefit from mosh's predictive typing.
3. It was only a remote terminal replacement. If you're doing anything more over ssh (port forwards, x11 forwarding, etc) then you're going to run into all the normal ssh issues anyway.
4. You had to run a 3rd party script to kill old abandoned mosh sessions. This is a consequence of being able to re-attach after a broken connection: the mosh server has no idea if you're coming back or not, so it leaves your session there. At least with tmux I can list the active sessions, re-attach to them, see what they're doing, and destroy them at will. With mosh, you could only reconnect to an old session if you hadn't closed mosh on your laptop. If your laptop powered off (intentionally or not) then you could either play "guess which mosh pid to kill" or leave your mosh session running long enough for the mosh killer script to get it.
Also there was the issue of popularity/network effects. ssh is everywhere, mosh is not, and its hard to argue that mosh should be everywhere when I was getting only slight benefit from it. This isn't mosh's fault, any ssh competitor that isn't upstreamed into openssh is going to run into the same exact problem.
With my hypothetical ssh-over-QUIC I'm hoping for just plain-old ssh with all the normal features, just using QUIC instead of TCP. Ideally upstreaming into openssh. I know there are a bunch of projects out there attempting something like ssh-over-QUIC but I think it has to be upstreamed and a drop-in replacement to overcome the popularity moat regular ssh has built.
A few other issues I do remember running into (probably 10 years ago?):
1. Because it was udp, sometimes a captive portal, work, or hotel firewall blocked it.
2. It was also not installed by default anywhere, so sometimes sysadmins at work were unwilling to install it for me.
3. I sometimes ran into issues with color handling and utf8. I honestly don't remember if it was mosh or my terminal, though. It seemed to happen more often when I used mosh, but I could be misremembering.
I suppose this didn't always use to be the case, though.
Mosh is a lifesaver
I can't speak to Claude, but Emacs and Vim work well in it.
At the same time, in recent years, I've found that ssh running on top of Wireguard / Tailscale is way more usable than 2013 days. Those latter tools address the roaming IP issues directly at the network layer.
So while there are still issues with ssh / TCP if you're on a really crappy network (heavy packet loss, satellite link, etc), those have been less common in my experience compared to IP changes.
The “killer use case” for Mosh feels a lot less killer now.
It definitely solves problems when traveling and dealing with crappy airport/hotel/AirBnB/conference wifi that is slow or overloaded.
Mosh means a lot less, "Sigh..." up-arrow, enter. A small thing, but why live with it when you can just not?
1. whether your IP is persistent (ie you can reuse the same socket)
2. your SSH keep alive settings
3. and how quickly your OS can wake up it’s network stack
If the socket persists, then it should be possible to allow SSH to survive longer periods of network inactivity given the right keep alive settings.
When I used to work with on prem systems, I’d run non-standard ssh keep alive so I could bounce network switches without losing access to servers sat in between.
Yes, flattery works, pandering-to-ego works. Too bad, you can only push it so far...at some point, CTO/CEO notices.
We managed to survive with our solution for a while thanks to it being super simple and "free" besides the instance running wireguard. Last I heard (I left), they shut that all down a few years ago.
I used to use mosh, tmux before but always got annoyed how they broke scrolling , searching etc.. Especially when yakuake already provides half the functionality i used to rely on tmux for..
I also enjoy the ability to quickly launch/manage Digital Ocean instances useful sometimes as well.
Not leaving pull requests for over half a decade fixing critical issues with not even bothering to comment on them would probably be a massive advantage over Mosh.
one thing to consider though is how a large download over an ssh tunnel effectively prevents any other connection through the same tunnel from working.
to fix that possibly sshuttle can provide some inspiration. they solved that problem.
sshfs may be tricky, because it could lead to locked/hanging file access that never comes back if the server goes away. i don't know what the best approach here is. maybe some sort of timeouts, or maybe do let it hang but provide diagnostics with a command that can tell you what the status of the mount is, and force an unmount or restart of the connection if the user knows that the server went away.
aside from that it would just be nice if i would not have to manually remount every time the ssh connection drops.
another feature that i wish mosh had is to be able to reconnect to an existing session even with a restarted client. i don't know what it takes to do that. perhaps you need to store the keys that were used last time on disk which could lead to some concerns, but maybe that file on disk can be protected, or maybe that is not even necessary. i can attach to an existing tmux session, so if the mosh session is treated like that, it would work too?
[1]: https://github.com/p0deje/vagrant-mosh
Note: Mosh does not natively support agent forwarding similar to ssh. Creator of Mosh explained why in this comment https://github.com/mobile-shell/mosh/issues/120#issuecomment...
How ‘Mosh’ Rescued Me from Connection Hell: A Remote Work Story - https://news.ycombinator.com/item?id=35639011 - April 2023 (2 comments)
Mosh: An Interactive Remote Shell for Mobile Clients (2012) [pdf] - https://news.ycombinator.com/item?id=33717028 - Nov 2022 (37 comments)
Mosh 1.4.0 Released - https://news.ycombinator.com/item?id=33439542 - Nov 2022 (12 comments)
Mosh's tolerance for high packet loss helps a guy escape from an elevator - https://news.ycombinator.com/item?id=28157117 - Aug 2021 (34 comments)
Mosh: The Mobile Shell - https://news.ycombinator.com/item?id=28150287 - Aug 2021 (153 comments)
Mosh - https://news.ycombinator.com/item?id=22810589 - April 2020 (148 comments)
Mosh - https://news.ycombinator.com/item?id=18692618 - Dec 2018 (9 comments)
Mosh v1.3 Released - https://news.ycombinator.com/item?id=14228591 - April 2017 (69 comments)
ASK HN: How does mosh shell use UDP but provide reliability like TCP? - https://news.ycombinator.com/item?id=12519557 - Sept 2016 (1 comment)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=12429203 - Sept 2016 (49 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=11572146 - April 2016 (147 comments)
Mosh, the SSH Alternative Option for System Administration - https://news.ycombinator.com/item?id=11208757 - March 2016 (2 comments)
Mosh – a robust, responsive replacement for SSH - https://news.ycombinator.com/item?id=8928506 - Jan 2015 (45 comments)
Mosh: A replacement for SSH - https://news.ycombinator.com/item?id=8252093 - Sept 2014 (122 comments)
Mosh (mobile shell) - https://news.ycombinator.com/item?id=6321474 - Sept 2013 (6 comments)
Do you use Mosh? (SSH replacement) - https://news.ycombinator.com/item?id=5729004 - May 2013 (4 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=5016745 - Jan 2013 (89 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=4588239 - Sept 2012 (1 comment)
Mosh: SSH for 2012 - https://news.ycombinator.com/item?id=3819382 - April 2012 (193 comments)
Mosh: the mobile shell - https://news.ycombinator.com/item?id=3814589 - April 2012 (2 comments)
It's terrific for making high latency connections feel like a normal one, roaming between WiFi, cellular, and different VPNs without skipping a beat. Even in 2025 it is very useful.
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/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