# tty7: a Rust terminal workbench where the server owns the shells

> tty7 puts persistent sessions, SSH, git and coding-agent awareness behind one gpui-rendered window, with a background daemon holding the PTYs. It is a young project with a nightly channel, so the question is whether its architecture fits how you work.

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

- Repository: https://github.com/l0ng-ai/tty7
- Website: https://github.com/l0ng-ai/tty7/releases/latest
- Stars: 1,120 · Forks: 86
- Language: Rust
- License: Apache-2.0
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/l0ng-ai-tty7

## The problem tty7 picks: your window owns your shells

In most terminals the window process is the parent of every PTY. Close the window and the shells die with it, which is why tmux and its equivalents exist. tty7 inverts that: a background server owns the shells and panes, and the window is a client. The README states the consequence plainly, that you can quit or reboot and your shells and supported agent sessions keep running without tmux. That single decision is what the rest of the feature list hangs off. Persistent sessions, remote workspaces that survive a client reconnect, and a CLI that can drive panes with or without the GUI running all assume a server that outlives any one window. The audience is narrow and identifiable: people who run several coding agents at once across several repositories, and who currently juggle tmux sessions, an SSH client, a git GUI and a terminal emulator to do it. If you open one shell, run a build and close it, the architecture buys you nothing and costs you a daemon.

## How the server, the PTY and the gpui window fit together

The repository splits into a GUI binary and a framework-free core. Cargo.toml defines two binaries, tty7-app from src/main.rs and tty7-updater behind the updater feature, and depends on tty7-core, described in the manifest comments as the half that does not need gpui: the wire protocol, the session daemon, the PTY, the native SSH engine and the domain model shared with the headless tty7-server. Rendering comes from Zed's gpui plus gpui-component, and the VT parsing comes from alacritty_terminal. So the data flow is: tty7-server holds PTYs and session state, the GUI talks to it over a wire protocol, gpui paints the result. Two feature flags in that dependency line are worth reading closely. gssapi is off in tty7-core's defaults because a static musl tty7-server cannot link the system krb5 it binds, and the GUI turns it back on so managed SSH connections still offer gssapi-with-mic. remote-install is off for the mirror-image reason: it pulls an HTTPS client used only to download a tty7-server onto a remote machine, and the server binary is the thing being downloaded, so it can never take that path. Those comments are the most informative part of the manifest, because they document why the split exists rather than just asserting it.

## Installing tty7 and opening your first persistent pane

There is no package manager step in the README. Native builds for macOS, Windows and Linux live on the Releases page: a dmg for macOS arm64 and x86_64 to drag into Applications, a setup.exe or a portable zip for Windows, and an x86_64 AppImage for Linux that you mark executable and run, with X11 and Wayland libraries bundled. The README gives no Homebrew, winget or apt command, so treat the release artifacts as the supported path.

The agent-facing CLI is distributed separately as a skill. The README gives this pair of commands:

```sh
npx skills add l0ng-ai/tty7    # install
npx skills update tty7         # update later
```

Installing the skill is what lets an agent drive tty7 programmatically. The CLI itself is bundled with the application, and the README lists what it exposes: run streams a command and exits with its code, plus split, send, wait --until free and capture. The agent skill documents the interface, and the CLI reference lives in docs/cli/reference.mdx.

Agent status is a second, separate step. Detection is free and gives you the brand avatar, branch and diff, and tab title. Status requires one click under Settings → Agents to install that agent's hook, and that hook is what enables the status dot, notifications, the tray icon, tty7 wait, and resume after a reboot. Fork needs both the agent's own fork command and the hook.

## Where tty7 is the wrong tool

The persistent server is also the main liability. A daemon that outlives the window is one more process to reason about, and the README's own memory figure makes the shape concrete: cold-launch memory is 116 MB, broken down as 105 MB of GUI plus 11 MB of persistent server. Against Alacritty's 105 MB that is a modest overhead, but it is overhead you pay permanently rather than only while a window is open. If you want a terminal that is a terminal, this is a worse fit than the alternatives it benchmarks against.

The agent feature set is uneven by design, and the support matrix is honest about it. All nineteen listed agents are detected, but only eight also get status and resume: Claude Code, Codex, Grok, OpenCode, Oh My Pi, Droid, Qwen Code and Goose. Fork is narrower still, the same eight minus nothing in that list but with no others. Gemini, Copilot, Kimi Code and Pi stop at status and resume. Aider, Amp, Cursor, Auggie, Hermes, Vibe and Antigravity are detected only. If your agent is in that last group, tty7 will show you a tab title and a branch, and the tray icon, notifications and resume will not appear, because they depend on a hook the agent does not have.

Release cadence is the third constraint. The newest release in the list is a nightly, 26.8.4-nightly.202608290119, published alongside v26.8.3 and v26.8.2. A project shipping nightlies next to tagged builds is signalling that it moves fast, and the changelog entry for v26.8.3 describes a 151-fix polish pass, which is a lot of corrections in one release. That is a reasonable trade for early adopters and a poor one for anyone who needs a frozen, long-supported version.

## tty7 against Ghostty, Alacritty and Kitty

The comparison the README invites is against GPU-accelerated terminals, and the benchmark table is explicit about method: same machine, same day, same 155x40 grid, Apple M1 Pro, macOS 26.3.1, five-run averages dated 2026-07-04. tty7 reports 95 ms for an 11 MB cat against Alacritty's 239 ms, Ghostty's 179 ms and Kitty's 185 ms, and 888 fps on DOOM-fire against 485, 552 and 617. Methodology and a one-command reproduction are in scripts/bench/. Treat those numbers as the project's own measurement on one machine, not as a general claim, and note that the persistent server is part of why the comparison is not quite like for like.

The real difference is not throughput. Ghostty, Alacritty and Kitty are terminal emulators: the process you launch is the process that owns your PTYs, and their feature surface stops at the grid. tty7 adds a session daemon, a native SSH stack with profiles, keychain secrets, jump hosts, port forwarding and an SFTP panel, a git panel that follows the focused pane with stage, commit, amend, branch, push, stash, commit graph and worktrees, and agent awareness. If you want a fast emulator and nothing else, Ghostty or Kitty is the simpler answer, and tmux covers persistence if you need it. If you are already running tmux plus a git client plus an SSH config file plus a terminal, tty7 is arguing that those should be one program with one server behind them.

## Licence, updates and the cost of keeping up

tty7 is Apache-2.0, the same licence as the alacritty_terminal crate it builds its VT core on. That is a permissive licence, so redistributing a modified build is permitted provided you meet its notice and attribution conditions; the LICENSE file in the repository root is the authoritative text and this is not legal advice. Because publish = false in Cargo.toml, the project is not distributed through crates.io, which means there is no cargo install path and the release artifacts are the distribution channel.

Upgrades are handled in-app. The v26.8.2 release notes list in-app updates everywhere, and the manifest defines a tty7-updater binary behind the updater feature. There is a nightly channel as well as tagged versions, so you are choosing between them at install time rather than by accident. The upgrade cost that matters is not the binary swap, it is the hooks. Agent status depends on hooks installed per agent under Settings → Agents, so an agent that changes its hook format, or an upgrade that changes what tty7 expects, is where breakage would surface. The README does not document rollback, and it does not say what happens to running sessions across an upgrade, so if you depend on long-lived panes, test that on a non-critical machine before you rely on it.

## Conclusion

Adopt tty7 if you keep long-running shells or coding agents alive across reboots and want git, SSH and agent status in the same window; skip it if you need a stable tagged release, a plugin ecosystem or a terminal that is only a terminal. Before committing, check that your platform has a native build on the Releases page, install the hook for whichever agent you use under Settings → Agents, and confirm the tty7-server install path works on your remote hosts, since remote panes depend on it.

## FAQ

### Does tty7 keep my shells running after I quit the app or reboot?

Yes. A background server owns your shells and panes rather than the window, so the README states that you can quit or reboot and your shells and supported agent sessions keep running without tmux. Resume after a reboot for agents depends on installing that agent's hook under Settings → Agents.

### Which coding agents does tty7 support?

Nineteen are listed for detection, which gives a brand avatar, branch and diff, and tab title. Eight of them, including Claude Code, Codex, Grok, OpenCode, Oh My Pi, Droid, Qwen Code and Goose, also support status, resume and fork; the rest stop at detection or at status and resume.

### How do I install tty7 on macOS, Windows or Linux?

Download a native build from the Releases page. macOS ships dmg files for arm64 and x86_64 to drag into Applications, Windows ships a setup.exe or a portable zip, and Linux ships an x86_64 AppImage you mark executable and run, with X11 and Wayland libraries bundled. The README lists no package manager command.

## Sources

- [Official documentation](https://github.com/l0ng-ai/tty7/releases/latest)
- [Official README](https://github.com/l0ng-ai/tty7#readme)
- [Project repository](https://github.com/l0ng-ai/tty7)
- [Release notes](https://github.com/l0ng-ai/tty7/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/l0ng-ai-tty7