I Built tmuxhop So I Could Keep Coding From the Toilet

Kavan Chan — Sat, 25 Apr 2026 07:44:03 +0000

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:

tmuxhop on GitHub

DEV Community: Kavan Chan