A small local-first browser tool for hopping back into the same tmux session from your phone.
I didn’t build tmuxhop because I needed full remote access.
I built it because I was deep in a coding flow, had to step away from my desk for a few minutes, and didn’t want that flow to break.
Sometimes that means food. Sometimes that means taking a short break. Sometimes that means going to the toilet.
If you spend enough time vibe coding, you probably know the feeling: your terminal, editor, prompts, agent output, and half-finished thoughts are all lined up perfectly. You do not want to lose that state just because life interrupts for ten minutes.
My phone was already in my pocket. I just wanted the same session, on another screen, with as little friction as possible.
That is why I built tmuxhop.
The real problem was not remote access
At first glance, this sounds like a remote terminal problem.
But for me, it wasn’t.
There are already plenty of ways to SSH into a machine from a phone. Some of them are good. Some have mobile apps. Some support more features than tmuxhop probably ever will.
The problem was the friction.
For a short desk-to-phone hop, the usual setup felt too heavy:
- install a phone app
- configure SSH
- manage keys
- deal with client-specific setup
- think about security hardening
- then finally reconnect to the machine
That is all reasonable if your goal is “serious mobile remote access.”
That was not my goal.
My goal was much simpler:
I want to continue the same tmux session from my phone, immediately, in a browser.
That changes the product a lot.
What I actually wanted
I wanted something that felt like this:
- I am coding on my desktop
- my work is already inside
tmux - I need to get up for a bit
- I open my phone
- I open a browser
- I land in the same session
- I continue telling the AI what to do
- I stay in flow
That was the whole idea.
Not a full remote desktop. Not a secure internet-facing shell service. Not a general-purpose mobile terminal platform.
Just a fast continuation path.
That “continue easily” part became the real product idea.
Why tmux made this possible
The key insight was that I was already using tmux.
That meant I didn’t need to invent session persistence. I didn’t need to sync shell history. I didn’t need to make mobile and desktop behave like separate environments.
tmux was already doing the important part: keeping the session alive.
So tmuxhop only needed to do one job:
expose that existing tmux session in a phone-friendly browser UI.
That is why the name made sense to me:
-
tmux= the session continuity layer -
hop= jump to another device and keep going
The tradeoff I chose on purpose
I made tmuxhop local-first on purpose.
That means:
- no built-in auth
- no public internet story
- no “secure your shell for the world” pitch
- intended for same machine, LAN, or VPN only
Some people will look at that and say it is too limited.
That is fair.
But the limitation is also what keeps the product simple.
If I had tried to solve “mobile terminal access from anywhere securely,” I would have built a very different tool. The complexity would go up fast. The setup would get heavier. The product would become more about infrastructure than continuity.
I did not want that.
I wanted:
- open browser
- same session
- keep going
Sometimes a product gets better by not trying to solve the bigger problem.
What tmuxhop optimizes for
tmuxhop is optimized for a very specific workflow:
- you already live in the terminal
- you already use
tmux - you are often working with agents or long-running coding sessions
- you do not want to lose context during short interruptions
- you care more about continuity than perfect mobile-native terminal features
It is not optimized for:
- internet-facing access
- multi-user collaboration
- replacing desktop terminal tools
- being a full remote ops platform
That focus helped a lot.
The more I worked on it, the clearer it became that tmuxhop is not really a “mobile terminal app.”
It is a flow continuity tool.
Building it also reminded me how rough mobile terminal UX is
A normal desktop terminal is easy to take for granted.
A mobile browser terminal is not.
Once I started building tmuxhop, I ran into a lot of weird details:
- font rendering
- Nerd Font support
- terminal sizing across laptop and phone
- keyboard pop-up behavior
- viewport scrolling
- control placement on small screens
- the awkwardness of text input inside mobile browser terminals
A lot of the work was not glamorous. It was small UX friction everywhere.
That also changed how I think about developer tools.
The core idea can be simple and correct, but if the interaction details are annoying, the tool still feels broken. Especially on mobile.
Who I think this is for
If you:
- code in the terminal a lot
- keep your work in
tmux - use AI tools heavily
- work in bursts of deep focus
- hate losing context during short breaks
then tmuxhop might make sense to you too.
If you need a hardened remote shell product, it probably does not.
And that is fine.
I think it is good for tools to know what they are for, and what they are not for.
Final thought
I like building tools that remove tiny amounts of friction from real life.
tmuxhop is one of those tools.
It is not trying to be the biggest or most complete solution. It is just trying to solve one specific problem well:
keep the same coding flow alive when you have to step away from your desk.
If that sounds familiar, you can check it out here, appreciated if you can leave a star: