tmux on Windows: the options

What tmux does

tmux does three jobs. It keeps programs running after the terminal window closes. It lets you leave and come back later with the same panes and scrollback where you left them. And it splits one window into several panes, so one ssh connection holds a shell, a log, and an editor at once.

On Linux servers that combination is standard equipment. Windows ships none of it. tmux needs a POSIX pty layer Windows does not provide, so there is no official build, and everything below is a way around that. Each way gives up something different.

WSL: the standard answer

WSL gives Windows a real Linux environment, and tmux inside WSL is real tmux. Install WSL with wsl --install, open the Ubuntu distro it sets up, and run sudo apt install tmux. Panes, detach, scripts, plugins: everything the manuals describe works as described.

The cost is the seam between the two sides. Your panes run Linux programs, so Windows tools are an interop call away and Windows files sit under /mnt/c. Copying from a tmux pane into a Windows app crosses a second seam, because tmux's copy buffer knows nothing of the Windows clipboard until you wire the two together, usually with win32yank or a pipe to clip.exe. And the whole thing runs in a VM. The first start boots it; after that, sessions survive closing the terminal window because the tmux server keeps running inside the VM. A reboot or wsl --shutdown ends every session inside it.

For Linux work, that trade is usually worth it.

MSYS2 and Cygwin: tmux through a compatibility layer

MSYS2 and Cygwin port the POSIX layer tmux needs, and both package tmux directly: pacman -S tmux in MSYS2, or the tmux package in Cygwin's installer. GNU screen is packaged the same way, if screen is what you were after.

The panes are real and the keybindings are the ones you know. What breaks is the drawing. tmux renders through the MSYS2 or Cygwin pty emulation, while modern Windows terminals host programs through ConPTY, a different design, and the translation between them mishandles resizes and cursor addressing often enough that full-screen programs can redraw wrong. When that happens you are debugging two pty implementations at once, and the tmux project tests against Unix terminals, not this stack.

Native ports and clones

psmux is a Rust reimplementation of tmux's pane and keybinding model. It runs natively on Windows with no WSL involved. tmux configs and scripts start from zero, and the feature set is whatever the project has reimplemented so far.

wtmux is a tmux-style multiplexer distributed through the Microsoft Store. Same shape as psmux: tmux's keyboard, an independent implementation behind it, and no carryover of tmux config.

tmux-windows on winget installs a package by that name. Before relying on it, check which tmux build it wraps and what that build needs for a pty, because that answer decides whether it behaves like the MSYS2 route above.

Whatever you pick, persistence is the part to check. Arranging panes is the easy half. Keeping the programs inside them alive after the window closes is the job that needs something holding them, and that is the half to test first.

Wintty Pro: the same jobs in the terminal

The third route skips tmux entirely. Wintty is a native Windows terminal, built on the Ghostty terminal core, and Wintty Pro builds the three jobs into the terminal itself.

Sessions run inside winttyd, a background daemon that starts when you log on. Close the Wintty window and the session keeps running in the daemon. An update that does not change the daemon leaves it running, so the session comes through the update. Reopen Wintty and the session is back with the same panes, the same layout, and the scrollback where you left it. If the session is attached in another window, the sessions picker takes it over after a confirm. The persistent sessions docs describe the whole lifecycle.

Panes belong to the session, not to the window. A session carrying four panes comes back as four panes, because the layout is stored with the session in the daemon rather than in window state.

New tabs and splits are persistent by default. Ctrl+Alt+T or Alt+click opens a plain tab that lives and dies with its window, and a setting restores the old default if you want persistence to be opt-in. Tokens and environment variables a restored session carries are encrypted on disk for your user account. The winttyc command-line tool lists, creates, and scripts sessions from PowerShell, so the daemon is drivable without touching the GUI.

A reboot ends the sessions. The daemon starts at logon and holds them across closing the app and across updates; it does not carry them past the machine going down, and neither does anything running in them.

Wintty Pro renders through DirectX 12 and checks for feature level 12_0 at startup. Machines that cannot, including Remote Desktop sessions, take Pro Legacy, the same build with a DirectX 11 renderer, included with Pro. And WSL does not go away: open a distro in a tab when you want Linux tools, and tmux still runs there for the Linux side.

Which one fits

No Wintty build has been published yet, so there is nothing to download today. The source is free, and prebuilt builds are planned as a sponsor thank-you; the download page says where things stand. If you are weighing Wintty against the terminal you already have, compare sessions, deployment, and where Windows Terminal is still the right choice.

Wintty is built on the Ghostty terminal core and is not affiliated with the Ghostty project. We are big fans of Ghostty and hope this work lands in official Ghostty for Windows.