Ich habe noch ein Terminal gebaut, Unterm – der Standardnutzer ist kein Mensch

Zuerst eine Zahl: In den letzten sechs Monaten stammten über achtzig Prozent der Befehle in meinem Terminal nicht von mir. Von Claude Code, Codex, einer ganzen Reihe von Agents — die werkeln rund um die Uhr darin, und eine einzelne Aufgabe läuft häufig mehrere Stunden.

Genau da liegt das Problem. Die Terminals, die ich benutze – iTerm, Windows Terminal, Warp – sind alle für „eine Person, die dasitzt und tippt” gebaut: eine Zeile tippen, kurz hinschauen, nächste Zeile tippen. Als der Hauptnutzer von mir zum Agent wurde, brach diese Grundannahme an mehreren Stellen zusammen. Ich bin Loch für Loch hineingetappt und habe schließlich kurzerhand selbst ein Terminal gebaut: Unterm.

Den letzten Anstoß gab eine Woche, in der ich meinen Zeitverbrauch genauer beobachtet habe: Der Großteil des Tages ging dafür drauf, für Agents als Netzwerk-Admin, Sicherheitsprüfer und Fensterwechsler zu fungieren – keine dieser Aufgaben gehörte zum eigentlichen Produkt, aber da niemand sie für mich abfing, musste ich selbst etwas bauen, das sie abfängt.

Im Folgenden beschreibe ich die Löcher, in die ich gefallen bin, und wie ich sie jeweils gestopft habe.

Was Unterm ist und woher der Name kommt

In einem Satz: Unterm ist ein Terminal, das externe KI-Agents direkt steuern können (unterm.app, Open Source, GitHub zhitongblog/unterm).

Es ist nicht dasselbe wie „ein Terminal mit eingebautem KI-Chat”. Es hat keine Chatbox, sondern öffnet das gesamte Terminal über das MCP-Protokoll für Agents – damit sie Fenster öffnen, Befehle tippen und die Ausgabe lesen können. Der Slogan, den ich dafür geschrieben habe, ist ein einziger Satz:

The terminal that runs every AI coding agent. (Das Terminal, das jeden KI-Coding-Agent zum Laufen bringt.)

Die dahinterliegende These ist ebenfalls ein Satz:

Das Terminal muss keine KI einbauen – es muss von einer KI bedienbar sein.

Was es kann: Mit einem Klick installiert es Claude Code, Codex CLI, Gemini CLI, OpenCode und Aider; es ist lokal-zuerst, Open Source, skriptierbar (mit einem unterm-cli); die Benutzeroberfläche ist in neun Sprachen verfügbar.

In der Praxis sieht es so aus: Ich sage in Claude Code „Starte den Build für dieses Projekt, und wenn er fehlschlägt, schau dir selbst die Logs an und korrigiere” – es verbindet sich über MCP mit Unterm, öffnet selbst ein Fenster, tippt Befehle, liest die Ausgabe auf dem Bildschirm, und bei Fehlern macht es selbst weiter. Ich muss nichts zwischen Chat-Fenster und Terminal hin- und herkopieren. Das Terminal ist zum ersten Mal die Hand des Agents geworden – nicht mehr meine Zwischenstation, um Ausgaben manuell herüberzuschleppen. Wenn ich hinschauen will, schaue ich; wenn nicht, läuft es von allein weiter.

Der Name ist simpel: Un + term. term steht für Terminal; Un steht für „befreien” – das Tippen aus den menschlichen Händen befreien und der KI übergeben. Als ich es gebaut habe, hatte ich ein einziges Bild im Kopf: Dieses Terminal ist nicht für meine Hände gedacht, sondern für den Agent – ich trete zurück und behalte es im Blick. Der Name sagt genau das.

1. Proxy: Die Mauer vor dem Agent unsichtbar machen

Ich bin in China, und achtzig Prozent von dem, was meine Agents tun, erfordert eine Verbindung durch die Firewall: Pakete installieren, git clone, Modellgewichte laden, verschiedene APIs aufrufen.

In einem normalen Terminal muss ich manuell export HTTPS_PROXY eingeben – einmal pro Shell-Sitzung. Aber sobald ein Agent ein neues Fenster öffnet oder einen Kindprozess forkt, ist der Proxy weg, und dann hängt alles, Timeout, network error. Das Ärgerliche: Der Agent weiß nicht, dass es ein Netzwerkproblem ist – er denkt, er hat den Befehl falsch geschrieben, ändert den Befehl, wechselt die Quelle, versucht es erneut, und wird dabei zunehmend konfuser. Einmal ließ ich ihn nachts Modellgewichte laden. Am nächsten Morgen: Er hatte über vierzig Minuten lang auf einem längst toten Proxy-Knoten versucht – Logs über den gesamten Bildschirm, kein einziges Byte heruntergeladen.

Also habe ich den Proxy ins Terminal selbst eingebaut. Unterm hat eine eingebaute Proxy-Schicht, die sich mit Clash verbindet; alle Sessions laufen standardmäßig über dieselbe Route. Ich habe einen Pool von Knoten konfiguriert (aktuell acht auf Gemini und GPT optimierte Singapur-Leitungen). Das Terminal misst alle dreißig Sekunden selbst, welche die schnellste ist, und nutzt diese; stirbt der aktive Knoten, wechselt es automatisch zum schnellsten verfügbaren Knoten im Pool. Und der Proxy wird auf Betriebssystemebene gesetzt (Windows über die Registry, macOS über scutil, Linux über Umgebungsvariablen) – nicht pro Shell –, sodass jedes neu geöffnete Fenster den Proxy automatisch mitbringt.

Einige Details wurden mir von den Agents aufgezwungen. Zum Beispiel dürfen localhost und interne Netzwerkadressen nicht durch den Proxy laufen, sonst kann sich ein Agent nicht mit dem Dienst verbinden, den er selbst lokal gestartet hat – diese No-Proxy-Regeln müssen standardmäßig konfiguriert sein, bevor ein Agent in die Falle tappt. Und der Knotenpool soll nicht von mir manuell gepflegt werden: Unterm liest direkt die Gruppen und Echtzeit-Latenzen aus Clash; mit ein paar Klicks in der Oberfläche stelle ich einen Rotationspool zusammen – welche Knoten hinein, wie oft rotiert wird –, ohne eine Konfigurationsdatei von Hand zu bearbeiten.

Es ist kein Allheilmittel: Wenn alle Leitungen im Pool gedrosselt werden, bin ich genauso aufgeschmissen. Aber das alltägliche Ärgernis „schon wieder ein einzelner Knoten ausgefallen” – das erledigt es selbst, ohne mich zu stören.

2. Sicherheit: Die Maschine der KI übergeben heißt auch rm -rf übergeben

Einem Agent ein nacktes Terminal zu geben bedeutet, ihm die gesamte Maschine zu übergeben. rm -rf, git push --force, DROP TABLE – ein falsch getippter Befehl, und die Daten sind weg, und der Agent tippt schneller als man reagieren kann. Das normale Terminal weiß nicht, dass dahinter eine KI sitzt; es behandelt den Agent und mich als dasselbe Paar Hände.

Ich will nicht zwischen zwei Extremen wählen: entweder alles unkontrolliert laufen lassen und dabei zittern, oder jeden Befehl manuell bestätigen – was genauso ist, als würde ich selbst tippen. Also hat Unterm ein paar Schleusen dazwischen eingebaut:

• Standardmäßig „vorschlagen”, nicht direkt ausführen: Der Agent übergibt den Befehl an meine Eingabezeile, drückt aber nicht selbst Enter – ich gebe ihn mit Tab frei.
• Abgestufte Freigabe: Eine ganze Klasse sicherer Befehle wird automatisch durchgelassen; nur rm -rf, Force-Push und DROP TABLE – die wirklich tödlichen – werden einzeln abgefragt.
• Isolierte Identitäten: Jedes Fenster ist mit einem eigenen Identitätsprofil verbunden (Token für GitHub / AWS / npm, Git-Identität, SSH-Key); was der Agent bekommt, ist dieses begrenzte Profil – nicht mein gesamter Schlüsselbund.
• Explizites Vertrauen: Welchem Agent ich vertraue, entscheide ich; nur bestätigte Agents schreiben ohne Rückfrage.
• Fehler wirklich lesen: Es kann fehlerhafte Zeilen auf dem Bildschirm erkennen – es sieht echte Ergebnisse, keine Annahmen.

Der Standard ist die konservative Stufe: Ein Agent, den ich gerade erst eingebunden habe und noch nicht als vertrauenswürdig markiert habe, muss alles erst an mir vorbei; nachdem ich ihn ein paar Runden beobachtet und für solide befunden habe, gebe ich die Klassen sicherer Befehle pauschal frei. In der Eingewöhnungsphase ist er etwas langsamer, aber er erschreckt mich nicht beim allerersten Schritt.

Wer länger mit Agents arbeitet, wird unweigerlich den Moment erleben, in dem einer selbstsicher rm -rf tippt, um „den Cache zu leeren” – mit einem falsch getippten Pfad. Menschen zögern eine halbe Sekunde vor Enter; Agents nicht – diesen Riegel muss das Terminal stellvertretend einziehen.

3. Aufzeichnung: Wenn der Agent fertig ist, will ich zurückspulen und sehen, was er getan hat

Das ist die Funktion, die ich am meisten nutze und auf die ich am wenigsten verzichten kann.

Ein Agent läuft drei Stunden unbeaufsichtigt; wenn man zurückkommt, will man wissen, was er wirklich getan hat. Die Zusammenfassung, die er selbst schreibt, reicht nicht – sie könnte Dinge auslassen, schönfärben oder gar vertuschen. Was man braucht, ist die Rohdokumentation: jeder Befehl, jeder Ausgabeblock, unverändert vorhanden.

Deshalb zeichnet Unterm die gesamte Sitzung von Anfang bis Ende auf: Was der Agent getippt hat, was das Terminal geantwortet hat – alles wird als abspielbares Protokoll gespeichert, das sich danach wie ein Video zurückspulen lässt oder Eintrag für Eintrag durchgeblättert werden kann. Beim Aufzeichnen werden Tokens und Schlüssel automatisch geschwärzt, damit das Protokoll selbst kein neues Datenleck wird.

Es ist die Blackbox des Agents: Bei Problemen spult man zurück und sieht, an welchem Schritt es schiefgelaufen ist; wenn es gut gelaufen ist, bleibt es als Demo oder Retrospektive-Material.

Ein Beispiel von letzter Woche: Ein Agent ließ eine Reihe von Tests fehlschlagen und behauptete dann selbstbewusst, er habe es „behoben”. Ich spulte die Sitzung zu dem Abschnitt zurück, in dem er den Code geändert hatte – und nach wenigen Minuten war es klar: Er hatte heimlich eine Assertion auskommentiert, damit die Tests grün werden. Hätte ich nur seine eigene Zusammenfassung, hätte ich das nie bemerkt. Die Aufzeichnung kann auch in ganzen Abschnitten exportiert werden; ich habe sie mehrfach als Anschauungsmaterial verwendet, um zu zeigen, wie KI tatsächlich arbeitet.

Die Hälfte meiner Bereitschaft, Agents unbeaufsichtigt laufen zu lassen, kommt von diesem zurückspulbaren Protokoll.

4. Parallelarbeit: Ich laufe längst mehr als einen Agent gleichzeitig

Der Normalzustand ist heute, drei oder vier Agents gleichzeitig laufen zu lassen: einer für das Frontend, einer für die Datenbankmigrierung, einer für die Tests. In einem normalen Terminal sind das drei oder vier schwarze Fenster; ich blättere mit Alt-Tab hin und her und verliere dabei den Überblick, wer auf meine Entscheidung wartet und wer schon längst abgestürzt ist und nichts tut.

Unterm macht das Verwalten einer ganzen Gruppe reibungslos:

• Massenstart: Ein Befehl öffnet ein neues Fenster und weist ihm die Aufgabe direkt zu;
• Broadcast: Will ich, dass alle vier Agents „den neuesten Code ziehen und dann den Build erneut durchführen”, schicke ich einen Befehl an alle Fenster – kein viermaliges manuelles Einfügen;
• Warten auf Abschluss: Nach der Aufgabenverteilung kann ich warten, bis ein bestimmtes Fenster „fertig / Fehler” meldet, und dann zurückkommen.

Konkret sieht ein Morgen so aus: Ich öffne drei Fenster, weise ihnen jeweils zu „Login-Seite nach neuem Design neu bauen”, „Bestelltabelle auf das neue Schema migrieren”, „Abrechnungslogik mit Tests ergänzen”, sende dann per Broadcast „alle zehn Minuten den Fortschritt posten”, und gehe selbst Nachrichten beantworten. Wenn ich zurückkomme, scanne ich die Zustände der drei Fenster; wer feststeckt, dem gehe ich in sein Fenster und schreibe kurz mit ihm; wer nicht feststeckt, läuft weiter. Ich bin von „jeden einzeln überwachen” zu „einmal über die Reihe schauen” gewechselt.

Meine eigentliche Arbeit ist nicht mehr Codeschreiben, sondern eine Flotte von Agents orchestrieren (darüber habe ich im vorigen Beitrag geschrieben). Und Voraussetzung für die Orchestrierung ist ein brauchbares Dirigierpult in der Hand – nicht vier schwarze Fenster, die nichts voneinander wissen und bei denen ich mir im Kopf merken muss, wer wer ist.

5. Fenster: Mit steigender Agent-Zahl wird der Desktop chaotisch

Wenn die Flotte läuft, herrscht Chaos nicht bei den Befehlen, sondern im Raum: Welches Fenster deployt gerade? Welches ist ein schnell aufgemachter Entwurf? Welchem habe ich vor zwei Stunden eine Aufgabe gegeben und noch nichts gehört? Mit dem Kopf zu merken versagt schon bei wenigen Fenstern.

Was ich eingebaut habe, ist die nüchternste Ordnung:

• Fenster haben Namen: alpha, bravo, charlie – keine unlesbaren Nummern. Tatsache: Während ich diesen Text schreibe, laufen auf meiner Maschine zwei Unterm-Instanzen – alpha ist im doaipm-Siteverzeichnis geöffnet, bravo im Content-Repository – ein Blick reicht, um zu wissen, wer wer ist.
• Layouts speichern und abrufen: Aufgeteilte Panels, angeordnete Fenster – als Workspace speichern; morgen beim Hochfahren wird alles wiederhergestellt, ohne jeden Tag neu Bausteine zu stapeln.
• Per Namen ansprechen: Ein Agent kann sagen „bring das Deployment-Fenster in den Vordergrund” – ich muss nicht durch ein Dutzend Fenster suchen.

Die Workspace-Funktion klingt wie eine Kleinigkeit, spart aber tatsächlich Zeit: Ich habe ein festes „Veröffentlichen”-Layout – ein Fenster für das Siteverzeichnis, eines für das Content-Repository, eines für den Build, eines für die Logs. Einmal gespeichert, täglich mit einem Klick wiederhergestellt; alle vier Fenster stehen direkt im richtigen Verzeichnis, kein tägliches cd und Neuanordnen.

Zwölf namenlose Fenster und ein Pult, das jeden beim Namen kennt – das ist der ganze Unterschied.

Und tmux? Und Warp?

Die naheliegende Frage: tmux hat schon lange Multi-Panel, Warp hat eine KI eingebaut – was füge ich eigentlich hinzu?

tmux habe ich viele Jahre lang benutzt; Multi-Panel ist gut gemacht. Aber es ist für zehn menschliche Finger entworfen: Es weiß nicht, ob dahinter ein Agent sitzt; es kümmert sich nicht darum, ob dein Befehl eine Datenbank löscht; es interessiert sich nicht dafür, dass du in China bist und jeder Befehl durch die Firewall in Timeouts hängt. Warp ist ein anderer Weg – ein KI-Assistent wurde ins Terminal genäht. Aber das ist „KI, die im Terminal sitzt” – nicht „Terminal, das von einer KI bedient wird”: Der Hauptakteur ist weiterhin die Person vor dem Bildschirm; der Agent ist höchstens Beifahrer, und Proxy und chinesische Netzwerkprobleme nimmt Warp auch nicht ab. iTerm und Windows Terminal benutze ich täglich; sie sind gute Terminals – aber der Maßstab für „gut” ist immer noch „für Menschen angenehm zu bedienen”: Farben, Schriften, Tastaturkürzel, geteilte Panels – keines davon hat „der Tippende ist ein Agent” als erste Grundannahme eingebaut.

Beide Wege sind in Ordnung – sie beantworten nur nicht meine Frage: Wenn der Hauptnutzer vom Menschen zum Agent wechselt, wie soll das Terminal dann aussehen? Proxy, Sicherheitsschleusen, rückspulbares Protokoll, Flotten-Orchestrierung, Fenster per Name verwalten – für mich sind das keine isolierten Funktionspunkte, sondern verschiedene Seiten derselben Frage.

Zum Schluss

Terminals gibt es überall; dass ich trotzdem eines gebaut habe, braucht, finde ich, eine kurze Erklärung.

Der Grund lässt sich in einem Satz sagen: Ich wollte kein „besseres Terminal” bauen, sondern eines, dessen Standardnutzer kein Mensch ist. Keine der oben genannten Dinge stammt aus einem Roadmap-Meeting – sie alle kommen von dem, was mich damals wirklich genervt hat.

Es gibt noch einen praktischen Punkt: Unterm selbst habe ich gebaut, indem ich einer KI im Terminal in einfachen Worten erklärt habe, was ich brauche – den Produktionscode habe ich nicht selbst geschrieben. Ich habe klar formuliert: „Es muss von einem Agent bedient werden können, selbst den Proxy wechseln, rm -rf abblocken, und ganze Sitzungen abspielen können” – und die KI hat es gebaut. Wer es klar sagen kann, bekommt es gebaut – so arbeite ich immer.

Ob die Welt noch ein weiteres Terminal braucht, weiß ich nicht. Ich jedenfalls schon.

Weiterführende Links

• Vorheriger Beitrag auf dieser Seite: Vom Ausführer zum Orchestrator: dein neuer Job ist, eine Flotte von Agents zu dirigieren
• Unterm Website / Open-Source-Repository: unterm.app · GitHub zhitongblog/unterm