WinMux: tmux for the Whole Windows Desktop

A window multiplexer for Windows: split panes, tabs and saved sessions, where every pane is a real process — a shell, a file browser or any Windows app.

Published on
Programming
C#.NETWindowsOpen Source

Source code: GitHub repository · Docs: rennerdo30.github.io/winmux

The problem

On Linux I live in tmux: one window, a tree of splits, and a session I can close and get back exactly as I left it. On Windows that workflow falls apart as soon as the work involves anything other than a terminal.

Windows does have tools for parts of this, but each one stops short:

  • Terminal multiplexers like Windows Terminal or WezTerm split panes nicely, but only for console programs.
  • Tiling window managers like GlazeWM or komorebi arrange any app, but across the whole desktop rather than inside one window you can save and restore.
  • Window tabbers like Groupy can put real applications into tabs, but they have no split layout and forget everything on restart.
  • Layout restorers like PowerToys Workspaces remember where apps were, but have no panes at all.

I wanted all of it in one place: a single host window with a tmux-style split tree, where a pane can hold PowerShell, a file browser, or Visual Studio, and the whole arrangement comes back after a reboot.

What WinMux is

WinMux is that host window. The layout is a tree, just like in tmux: horizontal and vertical splits, nested as deep as you like, with tab groups (stacks) anywhere in the tree. Every pane is one of four types:

  1. Terminal: PowerShell, cmd, pwsh, WSL or ssh, each running on its own ConPTY.
  2. File browser: a built-in dual-pane-friendly browser that can hand off to a terminal at the selected folder.
  3. Foreign app: any installed Windows application, picked from the Start Menu catalogue or adopted from a window that is already open.
  4. Empty: a placeholder you split first and fill later.

The keymap is tmux-flavoured: Ctrl+B is the prefix, and the rest follows from there.

Design decisions

A pane is a process, not a widget

WinMux does not emulate applications. Each pane is backed by a real, independent OS process, and foreign apps run behind their own isolated pane host process. If an embedded app hangs, it cannot freeze the shell, and closing WinMux does not have to take your work with it.

That isolation was not a guess. The first phase of the project was a set of measured spikes, and one of the findings was that a wedged application stalls its host no matter how it is embedded, unless the window calls are kept off the UI thread. So the pane hosts moved out of process.

Embed when possible, attach when necessary

There are two ways to get someone else’s window into a pane:

  • Embed reparents the application’s top-level window into the pane. It moves, clips and resizes exactly with the layout.
  • Attach leaves the window where it is and keeps its position and size glued to the pane, the way a tiling window manager would. Less seamless, far more compatible.

The default is auto, which consults a user-editable quirks file of measured per-app rules. If an app refuses to be embedded, WinMux keeps it running, says why, and switches it to attach. You can also flip the focused pane between the two live with Ctrl+B, then A, and the choice is saved.

“Any app” is still a measured surface rather than a promise. Elevated applications are limited by Windows’ integrity levels (and WinMux will not elevate itself to work around that), packaged UWP apps need attach, and apps with splash screens or several top-level windows need a rule to find the real one.

Sessions restore intent, not memory

Saving a session records the tree, the tabs, and each pane’s program, arguments and working directory, written atomically to a TOML file after every change. Restoring rebuilds all of that and starts the programs again. It deliberately does not try to resurrect process state such as in-flight jobs or TUI screens: that is a different, much harder problem, and out of scope.

Pane types are pluggable

Terminal, file browser and foreign-app panes are three implementations of one provider contract. Adding a fourth kind of pane should never require touching the layout engine.

Portability, honestly

The layout engine, session format, PTY contract and VT engine are platform-neutral, and all operating-system calls sit behind a single platform layer. Only the Windows runtime is built and verified, though. Embedding foreign windows is possible on X11 in principle, but impossible on Wayland and macOS, so there WinMux could only ever offer terminal panes and separate windows. WinMux is a Windows product; the portable seam is kept clean as a discipline, not as a promise.

Where it stands

The terminal multiplexer, persistence, foreign-app hosting, the file browser and the platform layer are done. The interface is most of the way through its first pass: nested tab groups with strips on any edge, a toolbar for every layout operation, Mica and the system accent colour, profiles, the application catalogue, window adoption and terminal scrollback. Still missing are tab and pane reordering, dragging a window into a pane, and scrollback search.

Builds are published as pre-releases on the releases page. WinMux targets Windows 10 1809 or newer and Windows 11; the getting started guide walks through the first session.