tmux on Windows: WSL2, Git Bash, and what actually works

There is no native Win32 build of tmux — it depends on a Unix pty layer Windows doesn't have. The practical option is WSL2, which runs a real Linux kernel and a real tmux. Git Bash/MSYS2 and Cygwin can technically launch a tmux binary, but pty emulation on both is incomplete enough that panes, resizing, and mouse support break in ways that make daily use painful. Use WSL2.

Why tmux doesn't just run on Windows#

tmux is built directly on Unix ptys (pseudo-terminals) and Unix process semantics — forking, signal handling, SIGWINCH for resize events. None of that exists natively on Win32. Every "tmux on Windows" option is really a Unix compatibility layer running tmux inside it, with whichever gaps that layer has.

Setting up tmux in WSL2#

Clipboard interop: the actual friction point#

Copying from tmux's copy mode doesn't reach the Windows clipboard by default — WSL2's Linux environment and Windows are still two separate clipboards until you wire them together. This is the Windows version of a problem every platform has; tmux on Mac covers the pbcopy side of it. Two tools do it here:

clip.exe is the zero-install option if you only need copy-out:

bind -T copy-mode-vi y send -X copy-pipe-and-cancel "clip.exe"

For paste-in too, install win32yank and bind both directions:

bind -T copy-mode-vi y send -X copy-pipe-and-cancel "win32yank.exe -i"
bind ] run "win32yank.exe -o | tmux load-buffer - ; tmux paste-buffer"

The gotcha: sessions dying when the last window closes#

This is the one that catches people who set up tmux in WSL2, walk away from a running session, and come back to find it gone. WSL2 runs each distro as a lightweight VM that Windows tears down automatically after a short idle period once every WSL window is closed — by default 60 seconds after the last WSL process disconnects, controlled by vmIdleTimeout in %UserProfile%\.wslconfig. A detached tmux session is still a running process, which normally keeps the VM alive, but if you've also enabled systemd=true in /etc/wsl.conf for real service management, some setups report the VM idling out anyway and taking the tmux server with it.

[wsl2]
vmIdleTimeout=-1

This is worth knowing before you enable systemd in the first place, not after a session vanishes. Most people turn it on chasing systemctl for a database or Docker daemon they want managed properly — if that's the goal, pair it with vmIdleTimeout=-1 from the start rather than debugging a disappearing tmux session later.

Git Bash and Cygwin, honestly#

If WSL2 genuinely isn't an option — a locked-down corporate machine, no admin rights to enable it — Git Bash can run tmux, but expect rough edges: pane splits sometimes misrender on resize, and SIGWINCH handling through MSYS2's pty layer is unreliable enough that a maximized window doesn't always tell tmux its new size. Cygwin's mintty is a better terminal for it than Git Bash's default console and gets you closer to correct behavior, but neither is what you'd choose if WSL2 were available. Treat both as a fallback, not a destination.

Checking a WSL2 session from outside Windows#

If you're running long jobs inside a WSL2 tmux session and want to check on them from your phone, the normal answer is SSH into the box and tmux attach — see tmux attach session for the mechanics, and tmux from your phone for what a 40-column SSH client actually does to a pane layout. Once tmux itself is running, the rest of your workflow — tmux commands, windows, panes, copy mode — is identical to any other Linux box; the same applies to tmux over SSH, which behaves no differently because the far end happens to be WSL2. If you'd rather open the session in a browser than arrange port forwarding into WSL2 first, that's what mtmux does — it runs inside WSL2 like anything else and serves the session out to whatever device you're holding (what it does, reference docs).

Worth being clear about what that does and doesn't get you: nothing pages you when a WSL2 build finishes. There is no push, no email, no Windows toast — you open the session and look at it, the same way you would by reattaching over SSH. The only thing that changes is what you need in your hand to do the looking.