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, a native reimplementation of tmux's command language, has its own entry under the alternatives below.

wtmux is a tmux-style multiplexer distributed through the Microsoft Store: 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.

tmux alternatives on Windows

Three projects run a multiplexer on Windows itself, with no WSL underneath. Each states its Windows support in its own docs, and each is the right pick for someone.

psmux is a native Windows terminal multiplexer written in Rust. It drives Windows ConPTY directly, speaks the tmux command language, reads your existing .tmux.conf, and supports tmux themes, all without WSL, Cygwin or MSYS2. It runs on PowerShell 7 or cmd.exe and installs with winget install psmux, Scoop, Chocolatey or Cargo. Its README lists split panes, multiple windows, session persistence, and detach and reattach. If you want tmux's keys and config on native Windows, psmux is built for exactly that. The Wintty and psmux comparison covers its per-session servers and the psmux-resurrect plugin that restores sessions after a reboot.

Zellij describes itself as a terminal workspace. Version 0.44 made it run natively on Windows, with the same session management, layouts and plugin system it has on Linux and macOS: download the Windows binary and run zellij.exe from PowerShell. Plugins can be written in any language that compiles to WebAssembly. Zellij saves each session's layout and the command in each pane, so after a quit or a crash it can resurrect the session and rerun those commands, behind a press-Enter prompt so nothing reruns by accident. If you want layouts, plugins and the same tool on Windows, Linux and macOS, it is the one to try. The Wintty and Zellij comparison sets session resurrection against a daemon that keeps the programs running.

WezTerm is a terminal emulator with a multiplexer built in, so there is no separate program to run inside it. It needs 64-bit Windows 10 build 17763 or later and installs with winget install wez.wezterm. Its multiplexer groups tabs and windows into domains: a unix domain, which WezTerm supports on Windows too, starts a server and connects the window to it, and an SSH domain attaches to WezTerm running on a remote machine. If you want one program for the terminal and the multiplexer, with remote attach over SSH, WezTerm covers it. The Wintty and WezTerm comparison covers its mux domains, detaching a domain, and attach over SSH and TLS.

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. The multiplexer docs map the common tmux commands to it: tmux ls becomes winttyc list, tmux new -s name becomes winttyc new name, and tmux capture-pane becomes winttyc history.

Running several coding agents at once is a common reason to want this. The page on running Claude Code and other AI agents in Wintty covers sessions, panes and the per-tab agent icon for that case.

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

FAQ

Getting Wintty

Prebuilt builds are on the download page, and Wintty Pro is the tier that carries the sessions and the multiplexer. 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.