ThinkRail macht aus Git-Worktrees einen Arbeitsplatz für Agenten

JetBrains hat die Angewohnheit, Werkzeuge auszuliefern, die annehmen, du wüsstest schon, was du tust. ThinkRail ist anders, und der Unterschied steckt in einem Satz des README: Öffne ein Git-Repository als Projekt und schneide daraus Arbeitsbereiche als Git-Worktrees.

Das ist die ganze These, und sie ist besser als „eine KI-IDE“. ThinkRail ist ein Inkubator-Projekt von JetBrains, rund 7.100 Sterne, 5.760 davon in der vergangenen Woche, und es ist um pi herum gebaut, den offenen Coding-Agenten. Was JetBrains hinzugefügt hat, ist kein Chat-Panel. Es ist die Verrohrung, die mehrere Agenten gleichzeitig arbeiten lässt, ohne dass sie sich auf die Füße treten.

Worktrees statt Hoffnung

Wer schon zwei Agenten auf demselben Repository laufen ließ, kennt den Fehlerfall. Der eine beginnt auth.ts zu bearbeiten, der andere beschließt, auth.ts zu refaktorieren, und du verbringst den Nachmittag mit Archäologie an einem Merge-Konflikt, dessen beide Seiten überzeugt sind, ihn geschrieben zu haben.

ThinkRails Antwort: Jeder Arbeitsbereich ist ein Git-Worktree mit eigenem Branch und eigenem Arbeitsverzeichnis. Die Agenten arbeiten parallel, und keiner fasst deinen Checkout an. Du mergst den Branch, der dir gefällt, und löschst den Rest.

Dazu kommt eine hübsche Aufräumregel: Erledigte und ruhende Arbeitsbereiche wandern von selbst auf ein Regal pro Projekt – wenn ihr Pull Request gemergt oder geschlossen wird oder nach einer ruhigen Woche – und kommen zurück, sobald du wieder darin arbeitest. Wer schon zwanzig veraltete Branches namens fix-thing-2 hatte, bekommt hier ein Feature, von dem er nicht wusste, dass er es wollte.

Die Topbar verfolgt, wo der aktive Branch gegenüber origin und seinem Pull Request steht, und legt den nächsten Schritt einen Klick entfernt: veröffentlichen, pushen oder einen PR öffnen, beschrieben aus dem Plan, den Commits, deiner Vorlage oder einem vom Agenten geschriebenen Entwurf. Ist der PR offen, zeigt sie CI-Prüfungen und die Review-Entscheidung und gibt fehlschlagende Checks oder einen divergierten Branch an den Agenten zurück.

Der IDE-Teil ist echt, nicht Dekoration

Teilbare Monaco-Tabs, ein Dateibaum mit Live-Markierungen für Git-Änderungen, eine Ansicht der geänderten Dateien, Terminals und Dokumente – alles auf den aktiven Arbeitsbereich beschränkt. Du kannst verankerte Review-Kommentare auf Dateien und Diffs setzen und sie als strukturierten Kontext in einen Chat schicken. Oder den Worktree in deiner installierten IDE öffnen, was das ehrliche Eingeständnis ist, dass manche von uns immer noch WebStorm wollen.

Chats streamen mit Live-Anzeige von Token und Kosten pro Session – die Art Detail, die nur auftaucht, wenn die Leute, die das bauen, ihre Rechnungen selbst zahlen. Du kannst einen laufenden Turn steuern, einen Folgeschritt einreihen, an Subagenten delegieren und an einem gemeinsamen Plan arbeiten, den der Agent aktualisiert, während du ihn bearbeitest. Jeder abgeschlossene Schritt lässt sich einzeln committen und prüfen, was eine viel bessere Review-Einheit ist als „hier sind 38 Dateien“.

Die Befehlspalette auf ⌘K oder per Doppel-Shift findet Chats, Arbeitsbereiche und Projekte über alle offenen Projekte hinweg. Ohne Eingabe listet sie die Chats, die auf dich warten – der richtige Standard für ein Werkzeug, das viele Sessions führt.

Specs als das, was überlebt

Das Feature, zu dem ich immer zurückkomme, ist der Spec-Graph. Ein zusammenhängender Satz SPEC.md-Dateien liegt neben dem Code, und der Agent liest, durchsucht und pflegt ihn über eigene spec_*-Werkzeuge. Das schreibgeschützte Specs-Werkzeug rendert den Graphen als Baum in der Workbench.

Die Begründung ist stichhaltig. Kontextfenster enden. Sessions enden. Was bleibt, ist das, was du aufgeschrieben hast. Die meisten Agent-Werkzeuge behandeln „den Plan merken“ als Gedächtnisproblem; ThinkRail behandelt es als Dokumentationsproblem – die Variante, die ein Mensch auch sechs Monate später lesen kann.

Es ist zugleich das Feature, das am ehesten verrottet. Ein Spec-Graph, den der Agent pflegt und niemand prüft, wird zu einer sehr selbstsicheren, sehr detaillierten Beschreibung von Software, die es nicht mehr gibt. Die Werkzeuge machen die Pflege billig; kostenlos machen sie sie nicht, und die Disziplin liegt bei dir.

Installation

Zwei Formen, beide additiv: ein nativer Desktop-Installer und eine in sich geschlossene CLI, die dieselbe App im Browser öffnet. Beide veröffentlichen SHA256SUMS auf der Releases-Seite.

Kommandozeile unter macOS oder Linux und unter Windows in Git Bash:

curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

Windows, aus cmd oder PowerShell:

powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"

Dann:

thinkrail ~/code/my-repo

Du brauchst git im PATH und einen Modellanbieter. Melde dich in der App mit JetBrains AI an oder verbinde einen beliebigen Anbieter über die eigene Authentifizierung von pi. Es gibt keine ThinkRail-Konten – ein Satz, den ich von JetBrains nicht erwartet hätte.

Desktop-Builds unter Linux brauchen glibc 2.38 oder neuer mit GTK 3, WebKitGTK 4.1, Ayatana AppIndicator 3 und librsvg 2 – praktisch also Ubuntu 24.04 oder später. Der Updater erscheint nur, wenn das Paket eine gültige HTTPS-Feed-Identität trägt; Installationen, die älter sind als diese Identität, brauchen einmal eine manuelle Installation.

Das Detail, das es portabel macht

ThinkRail liest deine bestehende Konfiguration unter ~/.pi/agent. Mit PI_CODING_AGENT_DIR kannst du sie woanders hinlegen, wenn du ein Arbeitsprofil pflegst. Unter Settings verbindet „Custom servers“ jeden OpenAI-kompatiblen Endpunkt – LiteLLM, sglang, vLLM, Ollama, LM Studio, llama.cpp – und schreibt ihn in die models.json von pi, sodass diese Modelle sowohl in der Chat-Auswahl als auch in der CLI auftauchen.

MCP-Server aus deiner mcp.json kommen mit, und zwar mit dem richtigen Verhalten: ThinkRail fragt im Chat nach, bevor es Server aufruft, die sich nicht als schreibgeschützt markieren, hält repository-definierte Server zurück, bis du sie freigibst, und meldet dich aus den Einstellungen bei OAuth-Servern an.

Agent-Erweiterungen sind ebenso pragmatisch. Die Einstellungen zeigen, was der Agent bekommt, lassen dich jede einzeln abschalten und installieren jedes pi-Paket aus einer Quelle – npm, Git oder ein lokaler Ordner – für dich oder für ein Repository. Die Werkzeuge für Rückfragen und Visualisierung sind als separate Pakete veröffentlicht, sodass ein nacktes pi im Terminal dieselben Multiple-Choice-Rückfragen und Inline-Diagramme bekommt.

Was ich beobachten würde

7.600 Sterne in einer Woche für ein Inkubator-Projekt sind viel Aufmerksamkeit für etwas, das noch keinen JetBrains-Release-Zyklus durchlaufen hat. Inkubator-Projekte bei JetBrains haben die Geschichte, entweder Produkte zu werden oder still aufzuhören, und Betas haben die Angewohnheit, die Version zu werden, von der man abhängt.

Das andere Risiko ist konzeptionell. Das ist ein sehr vollständiges Werkzeug mit vielen Oberflächen: Worktrees, Specs, Paletten, Erweiterungen, MCP, Themes, Schriften, vier eingebaute Sprachen mit dokumentiertem Weg, eigene hinzuzufügen. Jede davon ist ein Ort zum Konfigurieren statt zum Coden. Das beste Ergebnis für ThinkRail wäre, dass das Worktree-Modell so offensichtlich richtig wird, dass niemand mehr darüber spricht, und der Rest der App aus dem Weg geht.

Probier es, wenn du schon parallele Agenten laufen lässt und deine aktuelle Antwort „mehrere Terminalfenster und gekreuzte Finger“ lautet. Die Worktree-Isolation allein ist den Download wert. Probier es als normalen Editor, und du wirst merken, dass es keiner sein will.