The terminal is not the window
Malt is a structured terminal platform. The idea started from being dissatisfied with how much of a traditional terminal session effectively belongs to whichever emulator happens to be drawing it.
Normally the shell writes bytes and control sequences, the terminal emulator interprets them, and a great deal of meaning has to be reconstructed from that stream afterward.
Malt moves the important state into a daemon. The daemon owns sessions, panes, layout, input authority, and structured output. A TUI, a web client, another graphical client, or an automation tool can all be different views onto the same session instead of separate little worlds that happen to run shells.
That inversion is the part I care about. Most of the rest of the project follows from it.
It got large
At last count the repository had 19 Rust crates and a SvelteKit web client. There is an in-process POSIX shell called mash, a daemon, session persistence, a renderer, a compatibility layer for ordinary terminal programs, HTTP and MCP surfaces, a TUI, platform isolation work, and several other pieces that seemed perfectly reasonable one at a time.
This is a good example of what happens when I meet an interesting systems problem without sufficient adult supervision.
There is real software behind it, not just a design document. Sessions persist. Commands have history and lifecycle events. Output can stream while a command is running. Multiple clients can attach to a session with explicit input authority. The TUI speaks the same typed protocol used by other components.
It is also not a finished daily-driver terminal, and I do not want the project page to pretend otherwise.
Malt and Vexil
Malt uses VNP, the Vexil Native Protocol, for inter-component communication. The messages are typed, schema-defined, and encoded through Vexil rather than being a pile of handwritten wire structs.
That makes Malt one of the places where Vexil has to survive contact with a real system. The two projects are separate, but they are closely related in practice.
The part that changed how I work
The first development roadmap was phase based. It looked orderly and kept encouraging the project to spread sideways.
When I came back to Malt and started checking what actually existed, I found a recurring kind of failure that was more embarrassing than a missing feature: code could exist, have tests, and still have no production caller. Several things the roadmap said to build were already there. They simply were not connected to anything that made them useful.
That forced a change in how I worked on the project. I retired the old phase sequence and moved toward a correctness-first backlog built from running the system, checking reachability, and writing down evidence. The repository’s AGENTS.md now tells anyone working on Malt not to trust status claims without rerunning the gates.
That rule was earned.
The lesson was not that planning is bad. The lesson was that a large enough project can create a convincing paper reality where the architecture, tests, and roadmap all look healthy while the user-facing path still has a hole in it.
I am much more suspicious of that now.
Where it stands
Windows is the primary supported platform and Linux is supported as well. I do not currently claim macOS support because I do not have a machine where I can honestly test and debug it.
The basic session, shell, persistence, TUI, protocol, HTTP/MCP, history, streaming, and multi-client pieces are real. The structured-output side of the original idea still has important work left, along with the ordinary usability work that separates an interesting systems project from something I would want as my terminal every day.
Malt is probably the clearest example on this site of both sides of how I work. I can go very deep into a systems idea and build a surprising amount of it. I can also let the system become large enough that correctness and finishing need to become explicit disciplines rather than things I assume will happen at the end.
I am keeping both parts of that story here.