CLI tool
l0ng-ai/tty7 avatar
l0ng-ai/tty7

tty7: A Rust Terminal Workbench That Puts the Server in Charge

A terminal workbench in pure Rust: shells, persistent sessions, SSH, coding agents. GPU-rendered on Zed's gpui, VT core from Alacritty.

1,018 stars76 forksRustApache-2.0

At a glance

What is it?
tty7 is a GPU-rendered terminal workbench built on Zed's gpui and Alacritty's VT core, where a background server owns shells and panes. It targets engineers who want persistent sessions, SSH-native remote work, and agent awareness without tmux or wrappers.
Who is it for?
Adopt tty7 if you live in a terminal and want sessions that survive window closes, remote work without a file-sync layer, and agent status without wrappers. Skip it if you need a minimal terminal with a small memory footprint, or if you distrust a server process that outlives the GUI.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 19, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The Server-Owns-Everything Design

The core idea in tty7 is stated plainly in the README: a background server owns your shells and panes, not the window. This is a deliberate inversion of the usual terminal model, where the GUI process is the parent of your PTYs. Here, the server persists independently. Quit the window, reboot the machine, and your sessions keep running. The README claims you get persistent sessions without tmux, which is the direct comparison point. For anyone who has fought tmux attach/detach or lost work when a laptop died, this is the selling proposition. The server also enables agent-aware features: it can track status, send notifications, and resume sessions after reboot, because it does not depend on the GUI being alive.

How the Pieces Fit: gpui, Alacritty, and a Native SSH Stack

The rendering layer is gpui, the same GPU-accelerated UI framework used by Zed. The terminal emulation core comes from alacritty_terminal, so the VT parsing and rendering pipeline is inherited from a mature project. The SSH layer uses russh, a pure Rust SSH implementation. The README emphasizes that remote files, repos, panes, and git data stay on the remote machine, which means no local sync or mounting layer. This is a different architecture from tools that treat remote hosts as dumb shells. The server also injects shell integration when a pane starts, with no plugin to install. That integration provides prompt marks, working directory, exit codes, and command-finished notifications across zsh, bash, fish, PowerShell, WSL, and remote panes. The data flow is: the server manages the PTY, the shell integration feeds metadata back, the GUI renders via gpui, and the CLI talks to the server.

Getting It Running: Releases, CLI, and the Agent Skill

Installation is binary-only for now. Native builds exist for macOS (dmg), Windows (setup exe or portable zip), and Linux (AppImage with bundled X11/Wayland libraries). No package manager instructions appear in the README, so you download from the Releases page. Once installed, a bundled tty7 CLI provides commands: run streams a command and exits with its code, split, send, wait --until free, and capture. The wait command is notable because it lets an agent block until a pane is free, which is the kind of primitive you need for automated workflows. The agent skill installs via npx skills add l0ng-ai/tty7, and updates with npx skills update tty7. Configuration lives in config.json, and the README mentions agent_commands as a key to map wrapper scripts to agent names. Full docs are in docs/, including keyboard shortcuts and a CLI reference.

Agent Awareness Without Wrapping

The README is explicit: agents are not wrapped or proxied. You start the real Claude Code, Codex, or whatever, in a normal PTY. Detection is free and uses a brand avatar, branch and diff, and tab title. Status, which includes the status dot, notifications, tray icon, tty7 wait, and resume after reboot, requires installing a hook per agent under Settings. Forking requires both the agent's own fork command and a hook that tells tty7 which session to fork. The support matrix lists 19 CLIs, but not all are equal. Claude Code, Codex, Grok, OpenCode, Oh My Pi, Droid, and Qwen Code get full support: detection, status, and fork. Others like Gemini, Copilot, and Kimi Code get detection and status but no fork. Aider, Amp, Cursor, and others get only detection. That is a real constraint to check before you rely on it. The README also says an agent launched through a wrapper script can be mapped by name with agent_commands in config.json, which is a workaround but not a promise of full functionality.

Benchmarks: Read the Methodology Before You Quote Them

The README includes a benchmark table claiming roughly 2x the throughput of Alacritty, Ghostty, and Kitty on a 11 MB cat test, and 888 fps on a DOOM-fire demo versus 485 for Alacritty. Cold-launch memory is 116 MB total, split between the GUI at 105 MB and the server at 11 MB. These numbers are specific to an Apple M1 Pro running macOS 26.3.1, five-run averages on 2026-07-04. The README points to scripts/bench/README.md for one-command reproduction. I have not run these benchmarks, and you should not assume they transfer to your hardware. The memory figure is notable: 116 MB is higher than Alacritty's 105 MB, so the persistent server costs you about 11 MB even when you are not looking at the window. That is the price of persistence. The benchmark is a claim, not a fact, until you reproduce it.

Limitations and Failure Modes

The most obvious limitation is the memory overhead. A background server that never exits means a permanent process on your machine. If you are on a memory-constrained system, 11 MB for the server plus 105 MB for the GUI is not trivial. The README does not mention a headless mode or a way to stop the server without killing your sessions, so the trade-off is binary: you get persistence, or you do not. Another limitation is the agent support matrix. If your agent is only in the 'Detected' column, you get a brand avatar and branch info, but no status dot, no notifications, no wait, and no resume. That could be a dealbreaker if you depend on an agent that is not fully supported. The README also notes that SSH requires a one-time, unprivileged tty7-server install on the remote, which is an extra step that some remote environments may not permit. Finally, the project is young: the latest release is v26.8.3, and the changelog shows a 151-fix polish pass, which suggests active development but also that the API and config format may still shift.

Alternatives: tmux, Alacritty, and the Wrapper Approach

The direct alternative for persistent sessions is tmux. tmux runs as a server, too, but it is a separate tool you have to learn, configure, and manage. tty7's claim is that it gives you the same persistence without tmux, integrated into a GUI. The difference is that tmux is text-based and scriptable in a different way, while tty7 exposes a CLI with commands like wait --until free that are designed for agent orchestration. For a plain terminal emulator, Alacritty is the baseline. tty7 uses Alacritty's VT core, so the emulation is comparable, but Alacritty is a thin client with no server, no sessions, and no agent support. If you want agent awareness, the alternative is to run an agent inside tmux and write your own notification logic. tty7's approach is to build that into the terminal itself. The trade-off is that tty7 is a much larger application with a GUI, a server, and a config system, whereas tmux plus Alacritty is a composition of small tools.

Maintenance and License Considerations

The project is licensed under Apache-2.0, which is permissive for commercial use, but you should read the license text if you plan to redistribute. The release cadence is fast: v26.8.2 and v26.8.3 are days apart, and there is a nightly channel. That means frequent updates, which is good for bug fixes but implies a moving target. The README mentions in-app updates everywhere in v26.8.2, so keeping up is automated. The dependency on gpui and alacritty_terminal means you inherit their update cycles. The docs directory and a changelog exist, which is a good sign for maintainability, but the project is clearly in a pre-1.0 phase. You should expect config schema changes, as the agent_commands key suggests. The CLI is documented in skills/tty7/SKILL.md, which is an unusual but useful place for agent-facing documentation.

Editorial conclusion

Adopt tty7 if you live in a terminal and want sessions that survive window closes, remote work without a file-sync layer, and agent status without wrappers. Skip it if you need a minimal terminal with a small memory footprint, or if you distrust a server process that outlives the GUI. Before adopting, verify the benchmark methodology in scripts/bench/README.md on your own hardware, confirm your agent's hook support in the support matrix, and check the Apache-2.0 license terms for your distribution needs.

Official sources

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Community notes

Community notes