Warp: TUI Input View Ships First Milestone with Multi-Line Editing

Warp's TUI Input View Reaches Milestone 1

Warp has shipped the first functional milestone of its native TUI (Text User Interface) input view, a significant step toward enabling Warp to operate as a text-based terminal application alongside its existing GPU-accelerated GUI mode. Where Warp's current interface requires a graphical environment, the TUI rendering path will eventually allow developers to access Warp's capabilities in contexts where a GUI is unavailable or impractical, including remote SSH sessions, Docker containers, and headless CI/CD environments.

What the Input View Delivers

The TUI input view introduced in Milestone 1 centers on a proper multi-line editing experience, including support for Emacs/readline keybindings. For developers accustomed to terminal workflows, keybindings like Ctrl-A (beginning of line), Ctrl-E (end of line), and Ctrl-K (kill to end of line) are muscle memory. Having these available in Warp's TUI mode from the first milestone reduces the friction of adopting the new interface for developers who live in the terminal.

Crucially, the TUI input does not use a simplified standalone model. It reuses the existing CodeEditorModel and SelectionModel that power Warp's GUI editor, adapted for a character-cell coordinate space through a new CharCell rendering state. This means the text editing logic, selection behavior, and navigation model are shared between GUI and TUI modes, reducing long-term maintenance divergence and ensuring future editor improvements flow through to both surfaces.

The Technical Foundation

The milestone introduces a LayoutMode::CharCell path alongside the existing pixel-based layout, allowing the editor to operate in pure character-cell arithmetic rather than font shaping and pixel coordinates. Soft-wrap and offset calculations use integer character arithmetic in CharCell mode, making the editor functional in pure terminal environments with no rendering dependencies. The shared sub-model wiring means a developer familiar with the GUI editing experience will find the TUI input behaves consistently.

This work also introduces explicit column unit typing: ColumnUnit::Pixels and ColumnUnit::Chars discriminants ensure that GUI and TUI coordinate spaces remain separate at the type level, catching cross-space operations at compile time rather than at runtime.

Why a TUI Mode Matters for Warp

Warp has historically required a native application with GPU acceleration, which limits where it can run. The appeal of a TUI mode is straightforward: developers who use Warp on their local machine often also want to work in remote environments, whether a cloud VM, a container exec session, or a Linux server accessed over SSH. A TUI mode would allow Warp's agent and editing capabilities to follow the developer into those environments without requiring X forwarding or a remote desktop setup.

The TUI mode also complements Warp's growing CLI tooling. The warpctrl CLI and the oz command for triggering cloud agents already provide non-GUI access to parts of Warp's platform. A full TUI rendering path would extend that to interactive, real-time sessions rather than fire-and-forget commands.

What Comes Next

This is Milestone 1 of an ongoing TUI build-out. Subsequent milestones are expected to expand the TUI surface to cover block rendering, agent output display, and eventually a full TUI application comparable in capability to terminal-native coding agents such as Codex CLI or Claude Code. The foundation laid here, sharing models with the GUI and establishing the character-cell layout path, is what makes that expansion tractable without rebuilding core editor logic.