# term.everything: a Wayland compositor that draws GUI apps into your terminal > term.everything is a Linux CLI program that runs GUI windows inside a terminal, implemented as a from-scratch Wayland compositor. It is aimed at people who want a real desktop app over SSH, and it is still labelled beta. **mmulet/term.everything** — Run any GUI app in the terminal❗ - Repository: https://github.com/mmulet/term.everything - Stars: 8,103 · Forks: 196 - Language: Go - License: AGPL-3.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/mmulet-term-everything ## The gap term.everything is trying to close Terminal users have two bad options when they need a graphical program on a remote machine. They can forward X11 or run a remote desktop session, which assumes a graphical endpoint on the client side. Or they can look for a terminal replacement of the app, which usually does not exist. The README makes this argument directly, complaining that a new terminal file viewer appears constantly when you could instead use the file viewer you already have, in your terminal. term.everything targets that second option. It is a Linux CLI program that runs GUI windows in your terminal, and the README is explicit that it is a built-from-scratch Wayland compositor that outputs to a terminal rather than your monitor. That framing matters: the project is not a wrapper around an existing X server or a screenshot loop. It sits where the display server would sit, and the terminal becomes the display. The intended audience is narrow but concrete. People who live over SSH. People on machines where a graphical session is not available or not wanted. The README shows a video game running in a font inside a web browser in a terminal over SSH, and a full desktop, Firefox on KDE Neon in a VM, rendered into a terminal. The topics list on the repository points at alacritty, kitty, iterm2, wayland and ssh, which is a fair summary of who this is for. ## How a Wayland compositor ends up inside a terminal The repository layout tells most of the story. There is a wayland/ directory, an escapecodes/ directory, a framebuffertoansi/ directory, and a termeverything/ directory, with main.go at the top level. Those names describe a pipeline: something speaks the Wayland protocol to client applications, something converts a framebuffer into ANSI escape sequences, and something writes those sequences to the terminal. The build system confirms the protocol layer is generated rather than hand-written. The Makefile finds XML protocol files under ./wayland/generate, and generates Go files into ./wayland/protocols/ plus helper files into ./wayland/, driven by go generate ./wayland. So the set of Wayland interfaces the compositor understands is derived from protocol XML at build time. That is a normal approach for a compositor, and it means the surface area of supported protocols is visible in the tree rather than buried in code. The README points to resources/HowIDidIt.md for the detailed explanation of how everything works, and that file is the right place to go for the actual mechanism. What the README does state about output quality is a hard constraint worth internalising: the quality of the window is limited to the number of rows and columns in your terminal, and increasing the resolution raises quality while performance may go down. If your terminal supports images, the README says kitty and iterm2 are examples, windows can be rendered at full resolution, again with the caveat that performance may degrade. So there are two rendering paths with different fidelity and different cost. ## Installing term.everything and running a first app The README does not give install commands. It points at the releases page with the phrase Download the beta test now, and the current release line is 0.7.x, published as beta builds. So the first step is to take a binary from the releases page rather than to run a package manager command, because no package manager command appears in the README. The Makefile shows what a source build produces and where it lands. The binary name is constructed from dist/, an optional PLATFORM directory, an optional static directory, and an ARCH_PREFIX, ending in term.everything-mmulet.com-dont_forget_to_chmod_+x_this_file. That name is a deliberate reminder that the produced file is not executable until you change its mode. A source build from the repository root is a single make target, which generates the Wayland protocol bindings first and then compiles: ```bash make build ``` The generated protocol files are produced by this step, so a clean tree needs it before the Go build can succeed: ```bash go generate ./wayland ``` For the actual usage guide, the README sends you to resources/help.md and says to check the help file there for a usage guide on how to use term.everything. That file is not reproduced in the README, so the exact flags and invocation are not something this article can state. Read resources/help.md before your first run. When you do run an app, expect the terminal's row and column count to set the ceiling on quality. The README's own demonstration increases the resolution until it finds a balance between frame rate and resolution, and notes that ctrl - in alacritty is one way to change it. If your terminal supports images, that is the path to full resolution rendering. ## Where term.everything breaks, and what the roadmap admits The roadmap is unusually honest. Step one is checked off and labelled Term some things, with the parenthetical that some apps, or even most apps, may fail to launch or even crash, and a request to file an issue when that happens. Step two, Term most things, and step three, Term everything, are both unchecked. The project name is aspirational, not descriptive. That is the central limitation and it should drive the adoption decision. A Wayland compositor that is built from scratch will not have the protocol coverage of a mature one, and the build confirms coverage is generated from a set of XML protocol files that you can inspect. An application that depends on a protocol outside that set, or on behaviour a real compositor provides beyond the protocol, is a candidate for the failure mode the roadmap describes. The output medium imposes its own ceiling. Text cells are coarse, and the README states plainly that window quality is bounded by the terminal's rows and columns. Full-resolution rendering depends on terminal image support and is explicitly noted as potentially degrading performance. The README also mentions that running Doom required only a small amount of hacking, which is a signal about the general case rather than a promise about your app. One more constraint is easy to miss: the README describes term.everything as a Linux CLI program. The host systems discussed are x11 and Wayland, and the examples run on Ubuntu and KDE Neon, sometimes reached from a Mac over SSH. Nothing in the README describes running the compositor itself on macOS or Windows. ## How it differs from X11 forwarding and remote desktop The obvious comparison is X11 forwarding over SSH. With X11 forwarding, the application renders locally and the X protocol crosses the network; the client machine needs an X server, and the traffic is a drawing protocol. term.everything inverts that. The compositor runs next to the application, and what crosses the network is whatever the terminal session carries: escape sequences, and image data if the terminal supports images. The README's SSH example leans on exactly this, showing a browser session piped into a terminal over SSH. The second comparison is a remote desktop stack such as VNC or RDP. Those transport a pixel stream and reconstruct a full graphical session on the client, which means the client needs a graphical viewer. term.everything needs a terminal. The README's demonstration of an entire desktop in a terminal, Firefox on KDE Neon in a VM, is the closest thing to a remote desktop use case, and it still terminates in a terminal emulator rather than a viewer application. The practical difference is what you give up. X11 forwarding and remote desktop are mature and widely deployed; term.everything is beta, with a roadmap that says most apps are not yet covered. You trade compatibility for the ability to work from a plain terminal, including one that is itself inside another terminal, which the README demonstrates as terminals all the way down. ## Licence and what maintenance looks like The repository is licensed AGPL-3.0, and the README carries a copyright line for Late for Dinner Studios, LLC, dated 2025. The AGPL is a strong copyleft licence with a network clause, which is the part that matters for anyone who might expose modified behaviour to users over a network rather than distributing binaries. This article is not legal advice; if you plan to build a product on top of the compositor, read LICENSE.txt in the repository and get your own reading of the network clause. The last push to the repository was on 2026-03-18, so roughly six months have passed since the last recorded activity. The most recent release listed is 0.7.8, a beta, published on 2025-12-06, with 0.7.7 and 0.7.6 before it in the same 0.7 line. The repository is not archived. There is a ChangeLog.md at the top level, which is where release history is kept. Upgrade cost is hard to estimate from the README. The project is pre-1.0 and its own releases are labelled beta, so pinning a specific 0.7.x build is the cautious approach rather than tracking the branch. The build regenerates Wayland protocol bindings from XML on every build, which means a Go toolchain matching the go.mod requirement of go 1.25.2 is needed for source builds. The Makefile also supports a static build through the STATIC_BUILD variable, which is worth knowing if you intend to move the binary between hosts. ## Conclusion Adopt term.everything if you want a real GUI application, not a TUI rewrite, available over SSH or in a terminal on a Linux host, and you can accept that the README's roadmap still sits at 'Term some things' with apps that may fail to launch or crash. Do not adopt it if you need a supported, stable remote desktop replacement or a tool for non-Linux hosts, since the README describes a Linux CLI program and nothing else. Verify first that your target app launches at all, and check the resources/help.md usage guide before filing an issue, because that file is where the project puts its usage instructions. ## FAQ ### What is term.everything and what does it do? It is a Linux CLI program that runs GUI windows in your terminal, implemented as a built-from-scratch Wayland compositor that outputs to a terminal instead of your monitor. The README shows it running a browser, a file manager and a full desktop inside a terminal, including over SSH. ### Does term.everything work over SSH? Yes. The README's examples include running a video game in a font inside a web browser in a terminal transmitted over ssh, and the repository topics include ssh. The compositor runs on the remote Linux host and the terminal session carries the output. ### How do I install term.everything on Linux? The README does not give install commands; it links to the releases page with the phrase Download the beta test now, and the current releases are beta builds in the 0.7.x line. Building from source is a make build in the repository root, which first generates the Wayland protocol bindings. ### Can term.everything render windows at full resolution? The README states that if your terminal supports images, such as kitty or iterm2, you can render windows at full resolution, and adds that performance may degrade. Without image support, quality is limited to the number of rows and columns in your terminal. ### Is term.everything stable enough for daily use? The README's roadmap marks the first milestone, Term some things, as complete and warns that some apps or even most apps may fail to launch or even crash, asking users to file an issue when that happens. The remaining milestones, Term most things and Term everything, are unchecked. ## Sources - [Issues](https://github.com/mmulet/term.everything/issues) - [License: AGPL-3.0](https://github.com/mmulet/term.everything/blob/main/LICENSE) - [mmulet/term.everything on GitHub](https://github.com/mmulet/term.everything) - [README](https://github.com/mmulet/term.everything/blob/main/README.md) - [Releases](https://github.com/mmulet/term.everything/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mmulet-term-everything