--- title: "Superlogical Rex: Der Ghostty-Schöpfer denkt den Terminal-Multiplexer neu" description: "Rex ist Mitchell Hashimotos Terminal-Multiplexer: rohes PTY-Streaming an Clients, persistente Sessions, PAM-Remote-Logins, Lua-Config und eine skriptfähige CLI." date: 2026-10-08 categories: ["linux"] tags: ["rex","superlogical","terminal"] --- Rex ist der Terminal-Multiplexer, den Mitchell Hashimoto nach HashiCorp und Ghostty bei Superlogical gebaut hat. Es ist Terminal-Emulator und Multiplexer in einer einzigen nativen Anwendung: Du öffnest die App, bist in einem Terminal, und Sessions, Splits und Persistenz sind schon da. Der öffentliche Test [startete am 5. Oktober](https://www.superlogical.com/updates/public-testing-beginning) zuerst auf macOS; bis November hatten Tester den macOS-Client, die iOS-TestFlight-App und die Linux- und FreeBSD-Server in der Hand, die Docs sind öffentlich, und Hashimoto hat ausführliche Walkthroughs zur Funktionsweise veröffentlicht. ![Die Rex-macOS-App: Session-Tabs oben, geteilte Panes mit einem Codex-Code-Review, einem git-diff-TUI und einem Snake-Spiel](@assets/images/26/10/superlogical-rex-ui.webp) **Schon in der Beta?** Das November-Follow-up zeigt echte Tester-Workflows: Agents zeichnen Kitty-Graphics-Diagramme in geteilten Panes, Claude Code auf einem iPhone über Tailscale, wegwerfbare Cloud-VMs mit rex-cloud und eigene Lua-Sidebars. [Rex-Beta-Anwendungsfälle](/rex-use-cases/) **Noch auf der Suche nach einem Multiplexer?** Rex ist eines von sieben Tools in meinem Vergleich der besten Terminal-Multiplexer, neben tmux, Zellij, Herdr, TuiOS, Tern und Muxy. Wenn die aktuelle Desktop-Beta von Rex nicht zu deinem Setup passt, hat der Guide für jeden Workflow eine Empfehlung. [Alle 7 Multiplexer vergleichen](/de/beste-terminal-multiplexer/) ## Was Rex ist Rex läuft nicht in einem anderen Terminal, so wie [tmux](/tmux-basics/) in Kitty oder [Ghostty](/de/ghostty-terminal/) läuft – es ist das Terminal. Superlogicals Pitch lautet „ein Drop-in-Ersatz für jedes Terminal, das du heute nutzt", mit persistenten Sessions, Remote-Verbindungen und Programm-Aktivitätsstatus ([OSC 7501](https://www.superlogical.com/rex/docs/build/program-status)) obendrauf. Wenn ein Build, eine Terraform-Abfrage oder ein Coding-Agent arbeitet, auf Eingabe wartet, fertig ist oder fehlschlägt, zeigen nicht fokussierte Tabs und die Session-Liste diesen Status automatisch als Badge an. Das Vokabular besteht aus vier Substantiven, die in CLI und Config überall auftauchen: - Eine **Session** ist eine Arbeitsgruppe, meist ein Projekt. Der Server hält sie am Leben, egal ob jemand hinschaut oder nicht. - Ein **Window** ist ein Tab innerhalb einer Session. Es enthält ein Layout aus Blocks (und optional skriptbaren Floating Panes). - Ein **Block** ist eine Anwendung in einem Window. Heute heißt das: ein Terminal. - Ein **Client** ist ein Programm, das mit dem Server verbunden ist, etwa die macOS- oder iOS-App. Der Server besitzt alles. Clients attachen, rendern, detachen. App mitten im Build schließen, wieder öffnen – und du bist in derselben Session, wo du sie verlassen hast. Video: [Superlogical Rex: Der Ghostty-Schöpfer denkt den Terminal-Multiplexer neu](https://www.youtube.com/embed/2UNVvp-Xebw) ## Warum die Architektur anders ist (und warum das wichtig ist) Das ist der Teil, den es zu verstehen lohnt, denn er ist der Grund, warum Rex existiert statt nur ein weiterer tmux-Skin zu sein. Ein klassischer Multiplexer sitzt zwischen deinem Terminal-Emulator und dem PTY. Terminal → [tmux](/tmux-basics/) → Shell. Jedes Byte wird zweimal geparst: einmal vom internen Terminal-Modell des Multiplexers, einmal von deinem Emulator. Und historisch sind die Terminal-Kerne in tmux, screen und zellij langsam im Vergleich zu modernen Emulatoren. Hashimoto bringt es in seinem Architecture-Walkthrough auf den Punkt: Ghostty, Kitty und Alacritty sind bei Terminal-IO mitunter 100x schneller als der Emulator in einem Multiplexer – wer also einen davon vor sein schnelles Terminal schaltet, bekommt, in seinen Worten, „dieses langsame Erlebnis in einem schnellen Terminal". ![Wer den PTY-Stream parst: klassische Multiplexer sitzen zwischen Terminal und Shell und parsen Bytes zweimal; Rex verteilt rohe Bytes an libghostty-Instanzen pro Client](@assets/images/26/10/superlogical-rex-data-path.webp) Rex dreht um, wer parst: 1. **Der Server besitzt das PTY.** Wenn sich ein Client verbindet, pausiert der Server die PTY-Verarbeitung kurz und schickt einen eigenen Binärframe mit gerade genug State (Dimensionen, Cursor, aktueller Screen), damit der Client rendern kann. Dann ein Ready-Frame: Du kannst tippen, markieren und scrollen, während der Rest lädt. 2. **Rohe Bytes statt Screen-Diffs.** Statt ein geteiltes Screen-Modell zu pflegen und Diffs zu verschicken, tee-t der Server die rohen PTY-Bytes an jeden Client, wie SSH. Jeder Client nutzt libghostty und parst unabhängig. Falls der Server je langsam parst, ist das deinem Client egal. 3. **Scrollback streamt hinterher.** Neuester Chunk zuerst, mit Ladeanzeige, während die History nachgeladen wird. Und weil der Client seinen Viewport besitzt, können zwei attachte Clients in derselben Session unabhängig scrollen – das behebt das berühmte tmux-Verhalten, bei dem ein Scrollender den Screen aller anderen mitzieht. Zwei Konsequenzen, die man kennen sollte: - **Kein Multiplexing im Fenster.** Jeder Split ist eine eigene PTY-Verbindung, gerendert als nativer Tab, Split oder Window. Genau das macht iOS- und Browser-Clients möglich – und ist der Grund, warum ein tmux-artiger Pane-Baum nicht das Modell ist. Ein Legacy-Kompatibilitätsmodus für einfache Terminals (eine libghostty-Schicht in der Mitte, derselbe Tradeoff wie bei tmux, aber mit schnellerem Kern) wird noch diskutiert. - **Input bleibt zentral.** Tastatureingaben laufen seriell durch den Server, ein Writer und viele Reader, sodass der autoritative State nie forkt, selbst wenn ein Client aus dem Sync driftet. Ein gedrifteter Client wiederholt einfach den Handshake. Da der Client der Terminal-Emulator ist, folgt der Funktionsumfang libghostty. Die Kitty-Graphics-Lücke, die tmux nie geschlossen hat, ist genau die Art Sache, die hier out of the box funktioniert – auch über Remote-Verbindungen. ## Remote-Hosts: still und heimlich ein SSH-Ersatz Die zweite Demo ist die, die mich aufhorchen ließ. Rex ist nicht nur lokale Persistenz. Der macOS-Server hat Tailscale eingebaut (`tsnet`), und auf Linux und FreeBSD kannst du einen Rex-Server in drei Modi betreiben ([Docs zu den Server-Modi](https://www.superlogical.com/rex/docs/linux/server-modes)): **Personal** (`rex server start` als dein User), **Shared** (`rex.service` unter einem gemeinsamen `rex`-Account) oder **Login** (`rex-login-server.service` / `rex-login-server.socket`, läuft als root). Wenn du dich von der Mac- oder iOS-App mit einem Remote-Host verbindest, sieht das, was sich öffnet, aus wie SSH – ist aber kein SSH: - **Es macht einen echten System-Login über PAM.** Im Login-Modus prüft `rex-login-server` `/etc/rex/accounts.jsonc` (oder `services.rex.loginServer` auf NixOS), öffnet eine Login-Session für diesen OS-Account über `/etc/pam.d/rex-login-server`, wendet per-User-Ressourcenlimits und `systemd-logind` an und startet oder attacht den persönlichen Rex-Server dieses Users. Die Session taucht in `who` auf, und deine Login-Shell wird geladen. Die Sessions jedes Users laufen weiter, selbst wenn `rex-login-server` neu startet oder aktualisiert wird. - **`rex whoami` zeigt die Identitätskette.** Heute vertraut Rex dem Aufrufer auf Basis der Netzwerk-Identität (etwa deinem Tailscale-Login, z. B. `tailscale:alice@example.com`) – deshalb empfiehlt Superlogical Tailscale oder einen per SSH weitergeleiteten Unix-Socket. Voll eingebaute Authentifizierung und Support für bestehende SSH-Keys stehen auf der Roadmap, sind aber noch nicht aktiv. - **Es fühlt sich lokal an.** Hashimoto beschreibt, Architekturideen von Mosh für die Reaktionsfähigkeit übernommen zu haben, ohne volle Mosh-Parität zu behaupten. Eine Remote-Session per `rex session kill` zu beenden propagiert, bevor du die App wieder öffnen kannst. - **Alles Lokale funktioniert remote.** Der `Cmd+Shift+G`-Sprung ins Verzeichnis und Kitty Graphics funktionieren auch auf Remote-Hosts. „Alles, was lokal funktioniert, soll remote funktionieren" ist eine erklärte Designregel. Lokale Sessions brauchen nichts Remote. Remote-Hosts sind für den Fall, dass du dieselbe Persistenz auf einem Linux-/FreeBSD-VPS oder einer wegwerfbaren [Vercel-Sandbox-VM via `rex-cloud`](https://github.com/vercel-labs/rex-cloud) willst. ## Die rex-CLI und der Agent-Skill sind die Steuerungsoberfläche Jedes Terminal, das Rex öffnet, bekommt `rex` automatisch auf den PATH, plus drei Umgebungsvariablen, die der CLI sagen, wo sie ist: | Variable | Inhalt | |---|---| | `REX_SESSION` | ID der Session, zu der das Terminal gehört | | `REX_BLOCK` | ID des eigenen Blocks des Terminals | | `REX_SERVER` | Adresse des Servers, auf dem das Terminal läuft | `rex split` in einem Pane teilt also genau dieses Pane. Um woanders zu agieren, adressierst du mit `-s` (Session), `-w` (Window), `-b` (Block), `-C` (Client) oder `-S` (Server). Targets werden in fester Reihenfolge aufgelöst: volle ID, dann Label, dann Position, dann ein 4+-Zeichen-ID-Suffix. Ein mehrdeutiges Target ändert nichts: Es listet die Treffer und endet mit Status 3. ```sh rex ls # list sessions rex session inspect # details of the session you're in rex send -s build -w 2 'make test' # type into window 2 of the "build" session rex capture -b logs --trim # print the screen of the block labeled "logs" rex -S root@build.example.ts.net ls # sessions on a remote login server ``` Die meisten Befehle verstehen `--json` (stabile Ausgabe mit vollen IDs, für Skripte gedacht) und liefern aussagekräftige Exit-Codes: `0` ok, `1` fehlgeschlagen, `2` fehlerhafte Kommandozeile, `3` Target fehlt oder mehrdeutig, `4` Server nicht erreichbar, `130` unterbrochen. `rex wait` und `rex run --wait` übernehmen den Exit-Status des gewrappten Programms, sodass sich Skripte sauber komponieren lassen. Für AI-Coding-Agents installiert `rex skill setup` einen eingebauten Rex-Skill samt Session-Start-Hook in Claude Code (`~/.claude/skills/rex`), Codex, OpenCode und Pi (`~/.agents/skills/rex`). Statt Tokens damit zu verbrennen, CLI-Flags zu erkunden, weiß der Agent bereits, wie man Panes teilt, einen Dev-Server im Hintergrund startet oder Testfehler aus einem Nachbar-Block liest. Jeder andere Agent kann dieselbe Anleitung per `rex skill show` lesen. ## Konfiguration in Lua, mit eigenen Aktionen und Event-Listenern Die Config lebt in einer Datei: `~/.config/rex/init.lua` auf macOS und Linux, `%AppData%\rex\init.lua` auf Windows, `REX_CONFIG` überschreibt beides. Rex braucht gar keine Config, und mit `require` oder `dofile` kannst du eine große in modulare Dateien aufteilen. ```lua rex.bind("cmd+d", "pane.split", { direction = "right" }) rex.bind("ctrl+b>c", "window.new") -- tmux-style prefix chords work ``` Zwei Details aus den Docs, die man leicht übersieht: Der **Server** liest die Datei, deshalb muss `rex config reload` auf der Server-Maschine laufen und wird über eine Remote-Verbindung abgelehnt. Und es gibt kein File-Watching; Reload ist manuell. `rex config check` validiert eine Datei, ohne sie anzuwenden, ein fehlerhafter `rex.*`-Aufruf wird mit Fehler übersprungen, während der Rest der Datei trotzdem lädt, und ein harter Lua-Syntaxfehler behält die letzte gute Config. Eigene Aktionen sind benannte Lua-Funktionen, die mit `rex.action` definiert werden. Danach verhalten sie sich wie Built-ins: auf Keys bindbar, in der Command Palette auffindbar, per `rex do` von der CLI ausführbar: ```lua rex.action{ name = "scratch", title = "Open Scratch Window", run = function(ctx, args) rex.session.new_window{ layout = rex.layout.block{ flavor = "com.superlogical.terminal.shell", }, } end, } rex.bind("shift+cmd+n", "scratch") ``` Aktionen nehmen typisierte `args` (oder ein volles JSON-Schema als Lua-Tabelle), erhalten ein `ctx` (`session_id`, `block_id`, `client_id`, `origin`), rufen andere Aktionen über `rex.invoke` auf und reihen clientseitige Aktionen mit `rex.client.queue` ein. Zwei Hürden solltest du kennen: Die App akzeptiert Client-Aktionen von der CLI nur, wenn **Remote Control** in den Einstellungen an ist, und `rex do ~/.config/rex/init.lua --action scratch` führt eine Aktion aus einer Datei gegen die Live-Session aus, ohne die laufende Config anzufassen. Ein Lua-Skript, das per `rex do` läuft, kann außerdem Live-Server-Events über [`rex.on`](https://www.superlogical.com/rex/docs/automate/lua-events) abonnieren (etwa `terminal.pwd_changed`) und im Hintergrund weiterlaufen, um Blocks automatisch zu labeln oder Panes zu verwalten. In meinem [Guide zu Rex-Anwendungsfällen](/rex-use-cases/) siehst du, wie Tester Lua-Aktionen und Event-Skripte nutzen, um GitHub-PR-Panels, Claude-Code-Quota-Balken und automatisch fortgesetzte SSH-Tabs zu bauen. ## Wo du es laufen lassen kannst – und was es kostet - **macOS-App und iOS-TestFlight-Client.** Die macOS-App hostet selbst einen lokalen Rex-Server (mit eingebettetem Tailscale) und verbindet sich zu Remote-Servern; die iOS-App paart per QR-Code über Tailscale, um dieselben Live-Sessions anzuzeigen und zu steuern. - **Linux- und FreeBSD-Server sind jetzt verfügbar; Linux-/Windows-Desktop-Apps kommen als Nächstes.** Offizielle Server-Pakete gibt es für Debian/Ubuntu, RHEL/Fedora, SUSE, Alpine, NixOS und FreeBSD. Der Windows-Client (Anfang November in einer Pre-Alpha gezeigt) und die Linux-Desktop-App befinden sich noch im internen Test. - **Kostenlos, kein Account, selbst hostbar.** Superlogical erklärt, „Rex is and will always be free", Clients und Server „are not going to be directly monetized", und es wird keine Telemetrie gesammelt. Der Kommerzialisierungsplan wird vor dem Stable-Release versprochen. - **Zugang über die Mailingliste.** Einladungen gehen seit Oktober in Wellen raus; wer im Rex-Beta-Discord ist, kann außerdem der iOS-TestFlight-Alpha beitreten und Agents an Superlogicals Community-MCP anschließen. Für einen Platz trittst du der Mailingliste auf der [Ankündigungsseite](https://www.superlogical.com/updates/public-testing-beginning) bei. Die [Docs](https://www.superlogical.com/rex/docs/installation) sind öffentlich und auch ohne Zugang lesenswert; die Referenzen zu CLI, Linux-Server und Lua verraten dir das meiste darüber, was das Produkt ist. ## Rex vs. tmux vs. Herdr vs. Tern | | Rex | tmux / zellij | Herdr | Tern | |---|---|---|---|---| | Was es ist | Terminal-App + Multiplexer | Multiplexer in deinem Terminal | Agent-Control-Plane | Terminal + Workspace (native Blocks) | | Wie es rendert | Native Tabs/Splits, libghostty pro Client | Internes Screen-Modell, als Diff an dein Terminal | TUI über einem Session-Server | Native UI, Blocks über dem Tern Surface Protocol | | Remote-Story | Eingebautes Tailscale, PAM-Login-Server, Mosh-artige Reaktionsfähigkeit | Per SSH rein, dann attachen | SSH-Attach, Web-/Mobile-Clients | `tern remote serve` über QUIC, Web- und Mobile-Clients | | Config | Lua (`init.lua`) + `rex.on`-Events | tmux.conf / KDL | `~/.config/herdr` | Settings-UI + omp-Themes | | Scripting | `rex`-CLI, `rex skill`, Lua-Aktionen, `--json` | CLI + Shell-Skripte | Socket-API + CLI | `tern`-CLI, Events, `tern ctl`/`shot` | | Status | Öffentliche Beta (macOS- + iOS-Clients, Linux-/FreeBSD-Server) | Überall, seit Jahrzehnten ausgereift | Open Source, aktiv | Geschlossene Beta, Warteliste | Ehrlich eingeordnet: Das sind unterschiedliche Tools, die unterschiedliche Probleme lösen. tmux ist der Amtsinhaber mit Jahrzehnten an Muskelgedächtnis dahinter. Rex wettet darauf, dass der Multiplexer das Terminal sein sollte. Herdr ist gar kein Terminal; es ist eine Control Plane für AI-Coding-Agents (Agent-State-Sidebar, Socket-API, Marketplace-Plugins). Tern ist die Wette auf das Terminal-als-Workspace: dasselbe Server-owned-Session-Modell wie Rex, aber plattformübergreifend und mit Git-, SQLite-, Jupyter- und Kanban-Blocks plus einem nativen omp-Agent-Pane. Wenn Agents dein eigentliches Problem sind, starte mit meinem [Herdr-Review](/herdr-agent-multiplexer/) und den Guides zu den [besten Herdr-Clients](/best-herdr-clients/) und [besten Herdr-Plugins](/de/beste-herdr-plugins/). Wenn Terminal-Ergonomie das Problem ist, ist Rex das Interessanteste in diesem Bereich seit zellij, und mein [Tern-Hands-on](/de/tern-terminal/) behandelt den anderen ernsthaften Anwärter. Für das komplette Feld inklusive Zellij und TuiOS siehe den [Terminal-Multiplexer-Vergleich](/de/beste-terminal-multiplexer/). ## Bekannte raue Kanten - **Der Desktop-Client ist weiterhin macOS-only.** Linux- und FreeBSD-Server sowie der iOS-TestFlight-Client sind bei Testern, aber die Linux- und Windows-Desktop-Clients stecken noch im internen Test. - **Lokale Server-Neustarts behalten das Layout und verlieren die Shells.** Ein Update oder Neustart des lokalen Mac-Servers stellt deine Window- und Split-Anordnung als frische Shells wieder her (anders als `rex-login-server` unter Linux, der per-User-Server über Upgrades hinweg laufen lässt). Community-Erweiterungen wie `sshtab` in [rex-extensions](https://github.com/luongnv89/rex-extensions) umgehen das, indem sie Claude-Code- und Codex-Sessions nach einem Neustart automatisch fortsetzen. - **Der tmux-Workflow lässt sich nicht 1:1 übertragen.** Kein Pane-Baum im Fenster; Splits sind separate Verbindungen in nativen Containern. Prefix-Chords wie `ctrl+b>c` funktionieren in `rex.bind`, deine `.tmux.conf` nicht. - **Config-Reload ist manuell.** Noch kein File-Watching; `rex config reload` läuft nur auf der Server-Maschine. - **Remote-Auth stützt sich heute auf Netzwerk-Identität.** `rex-login-server` authentifiziert Aufrufer über Netzwerk-Identität (etwa Tailscale), gemappt in `/etc/rex/accounts.jsonc` und PAM; native Passwort-/Key-Auth und Support für bestehende SSH-Keys stehen noch auf der Roadmap. ## FAQ **Ist Rex kostenlos?** Ja. Superlogical sagt „Rex is and will always be free", kein Account nötig, Server sind selbst hostbar, und sie sammeln oder teilen deine Daten nicht. Was auch immer die spätere Kommerzialisierung wird – sie haben zugesagt, dass es nicht der Client oder Server selbst sein wird. **Kann ich Rex heute auf Linux, FreeBSD, iOS oder Windows nutzen?** Für **Server** ja: Linux- (Debian/Ubuntu, RHEL/Fedora, SUSE, Alpine, NixOS) und FreeBSD-Server-Pakete sind jetzt für Tester verfügbar, und wegwerfbare Linux-Sandboxes kannst du mit [rex-cloud](https://github.com/vercel-labs/rex-cloud) booten. Bei **Clients** sind die macOS-App und die iOS-TestFlight-App heute im Test, während die Linux- und Windows-Desktop-Clients noch in interner Entwicklung sind. **Ersetzt Rex tmux?** Es ersetzt die Aufgabe von tmux (Persistenz, Sessions, Splits, Remote-Attach) mit einem anderen Modell: rohe PTY-Bytes, die an Terminal-Emulatoren pro Client gestreamt werden, statt ein gemeinsames Screen-Modell. Was du verlierst, ist Pane-Verschachtelung im Fenster und Jahrzehnte an Ökosystem-Plugins. Was du gewinnst: Scrollback pro Client, native UI, Kitty Graphics über Remote-Links, erstklassiges Tailscale-/PAM-Remoting und eine skriptfähige Lua- und CLI-Oberfläche. Unser [tmux-Grundlagen-Guide](/tmux-basics/) zeigt, wie der Amtsinhaber-Workflow aussieht. **Funktioniert Rex mit meiner Ghostty-Config oder meinem Theme?** Nicht über einen direkten Datei-Import. Rex basiert auf libghostty und bringt eigene Theme- und Font-Einstellungen neben `~/.config/rex/init.lua` mit – erwarte also Engine-Vertrautheit statt eines Ghostty-Config-Importpfads. ## Die Kurzfassung Rex ist Mitchell Hashimotos These, dass ein Terminal-Multiplexer mitten in deinem Terminal kein Terminal emulieren sollte. Der Client parst, der Server streamt, Sessions persistieren, Remotes loggen sich über PAM via Tailscale ein, und das Ganze ist in Lua und per `rex skill setup` skriptbar. [Tritt der Mailingliste bei](https://www.superlogical.com/updates/public-testing-beginning), wenn du reinwillst, oder lies die [Rex-Beta-Anwendungsfälle](/rex-use-cases/), um zu sehen, was Tester damit bauen. Ebenfalls einen Blick wert: mein [Ghostty-Setup-Guide](/de/ghostty-terminal/) (dieselbe Engine steckt unter Rex' Haube), der [cmux-Guide](/cmux-terminal/), ein weiteres libghostty-basiertes Terminal mit Automatisierungs-CLI für macOS, und [Tern](/de/tern-terminal/), Stencils Rust-natives Terminal mit derselben Server-owned-Session-Idee, schon auf Linux, Windows und Android in geschlossener Beta.