vtm: a text-based desktop environment that runs the same on Windows and Unix

What vtm actually is, and who it is built for

vtm is not a terminal emulator in the usual sense. The README describes it as a virtual terminal multiplexer delivered as a single executable, and the second half of that description matters more than the first. It runs identically in native windows or standard consoles, wraps any CLI app, and supports infinite nesting. The stated goal is to bridge the gap between TUI and GUI by building a text-based desktop out of nested terminal surfaces.

The audience follows from that. Someone who already lives in tmux or screen but wants windows that tile, overlap and persist inside a single session is the obvious candidate. So is a Windows user who wants the same workspace model on a Windows console that a Linux user gets from a multiplexer, without installing a separate terminal program. The topics list on the repository includes windows-console and multiplexer, which matches the README's framing. Anyone looking for a drop-in replacement for a GUI desktop, or for a windowed terminal on Linux, is looking at the wrong project, and the README says so directly: rendering into a native GUI window is currently available only on Windows, and on Unix-like platforms a terminal emulator is required.

Infinite nesting and the DirectVT protocol

The mechanism the README puts forward is nesting. Because vtm is a multiplexer that can host itself, a vtm session can contain another vtm session, which can contain another. Each level is a real terminal surface with its own layout, so the desktop metaphor is built from the same primitive repeated rather than from a separate window manager.

Connection is handled through something the project calls the DirectVT protocol. The README gives one concrete example of why that matters: accessing vtm over SSH with the DirectVT protocol outperforms the classic connection, and the command shown is vtm ssh user@host vtm. The important detail is the trailing vtm. The remote side runs vtm as well, so the two ends speak the protocol to each other rather than exchanging raw terminal escape sequences. That is the architectural bet: the multiplexer is also the transport.

Above that sits VT2D and the AnyPlex protocol, both documented in doc/ and both marked Windows-only in the README for the demo. The README also lists HybridTUI, abbreviated HTUI, as a category of application, with calc, text and gems as concept examples rather than finished programs. The repository is C++ and links Lua, FreeType, HarfBuzz, lunasvg and stb, which tells you the rendering path is a real text-shaping pipeline, not a grid of monospaced cells painted by hand. The README does not document how the protocol is versioned or what happens when a newer client meets an older server, and that silence is worth noting before you put it between two machines you do not control.

Installing vtm and running your first session

There is no package manager step in the README. The project ships binary downloads from its GitHub releases, as 7z archives on Windows and tar.7z archives on Linux and macOS, split by architecture: x86_64, arm64, x86 and arm32 for Linux, x86_64, arm64 and x86 for Windows, and x86_64 and arm64 for macOS. Download the archive matching your platform and unpack it; the README does not give an install command beyond that, so the executable is what you run.

Once vtm is on your PATH, the simplest thing is to start the desktop environment. The README gives this as the whole instruction:

vtm

You should land in a text-based desktop rather than a shell prompt. If what you actually want is a terminal, the README offers a second mode that runs vtm as a standalone terminal emulator around a shell of your choosing:

vtm --run term [<your_shell>]

The square brackets are the README's notation, meaning the shell argument is optional; substitute something like /bin/bash or leave it out and let vtm pick. From there, the demo subcommands are the fastest way to see what the project is aiming at. On Windows, the README points at AnyPlex and VT2D through a single command:

vtm --run test

And the HTUI concept apps each have their own subcommand:

vtm --run calc
vtm --run text
vtm --run gems

The README labels these as concepts, so treat them as a look at the interface rather than as tools to depend on. For the SSH path, the command is short enough to type directly:

vtm ssh user@host vtm

Both ends need vtm for this to do what the README says it does.

The Windows-only rendering boundary

The clearest limitation is stated in the README itself, in small print under the platform list: rendering into a native GUI window is only available on the Windows platform, and on Unix-like platforms a terminal emulator is required. That single sentence changes what the project is depending on where you run it. On Windows, vtm can be the thing you launch, including on Windows Server Core and Windows PE, which have no GUI shell to speak of. On Linux, macOS, FreeBSD, NetBSD and OpenBSD, vtm is a guest inside whatever terminal you already have, and its visual ceiling is that terminal's.

That is not a defect exactly, but it is a fork in the product. A user on Linux gets a multiplexer with an unusual nesting model and a protocol for remote connections. A user on Windows gets a desktop environment. The README's own demo commands reinforce the split: the AnyPlex and VT2D demo is marked Windows only for now.

The second limitation is documentation depth. The README links to doc/architecture.md, doc/build.md, doc/command-line-options.md, doc/user-interface.md, doc/settings.md, doc/character_geometry.md and doc/anyplex.md, so the material exists, but the README itself gives no rollback guidance, no compatibility matrix for the DirectVT protocol across versions, and no statement about what a settings file does when a key is unknown. Releases arrive frequently, with v2026.07.22, v2026.07.30 and v2026.09.20 all appearing in the recent list, and the last push to master was on 2026-09-19. A fast release cadence on a young interface usually means configuration keys and command-line options move. If you are the kind of team that pins a multiplexer config and forgets it for two years, that cadence is a cost, not a feature.

How vtm differs from tmux and Windows Terminal

The honest comparison is with tmux, because that is what most people reading this already run. tmux is a session manager: it keeps processes alive across disconnects, splits a window into panes, and speaks a well-worn configuration language. It does not try to be a desktop, it does not render its own windows, and its remote story is SSH plus a terminal. vtm's difference is that nesting is the primary abstraction rather than a side effect of session grouping, and that the DirectVT protocol lets two vtm instances talk directly instead of through a stream of escape sequences. The README's claim that this outperforms the classic connection is a claim about the protocol, not a benchmark, and the repository does not publish numbers behind it.

On Windows the nearest neighbour is Windows Terminal. Windows Terminal is a host for shells and renders them well; it does not multiplex, and it does not nest. vtm, on Windows, does both, and can render into its own window rather than borrowing one. What Windows Terminal has that vtm does not document is a settled configuration format and a large body of written guidance. If your requirement is a terminal that just works and never surprises you, Windows Terminal is the safer pick. If your requirement is a workspace you can nest and carry over SSH, vtm is doing something the others are not.

One more contrast worth stating: the README's HTUI examples are concepts, not applications. A GUI application framework this is not, and the README does not claim otherwise.

Licence, upgrade cost and what to check before adopting

The repository is MIT licensed, which is permissive and places few obligations on how you redistribute or embed the binary. That is a statement about the licence file, not legal advice; if you are shipping vtm inside a product, read LICENSE and your own counsel's view of it.

The upgrade cost is the part to think about. Releases are dated and frequent, and the last push to master was on 2026-09-19, so the codebase is moving. The README documents settings in doc/settings.md and command-line options in doc/command-line-options.md, but it does not promise that either is frozen. Practically, that means treating vtm the way you would treat any tool with a young interface: keep your configuration in version control, read the release notes for the version you are moving to, and do not assume a settings key that works in one release survives into the next. Building from source is documented in doc/build.md and the top level carries CMakeLists.txt and CMakeSettings.json, so source builds are a supported path if you need to pin a commit rather than a release.

What the README does not address at all is rollback. There is no documented downgrade procedure, and no statement about whether a settings file written by a newer vtm will be read by an older one. If you deploy vtm across a fleet, that gap is the thing to resolve yourself before the first upgrade, not after.

Editorial conclusion

Adopt vtm if you want a keyboard-driven, nestable workspace that behaves the same over SSH as on a Windows console, and if you are comfortable with a project whose interface is still being shaped. Do not adopt it if you need a stable, documented configuration surface or a terminal emulator that draws into a window on Linux or macOS, because the README states that native GUI rendering is Windows-only for now. Before committing, download the release archive for your architecture, run vtm --run term $SHELL to confirm your terminal is among those that render correctly, and check doc/settings.md against the keys your current multiplexer already uses.

Frequently asked questions

Official sources

1. directvt/vtm on GitHub
2. Issues
3. License: MIT
4. README
5. Releases