Bei vier offenen IDE-Fenstern sieht man nicht mehr, welche Session gerade wartet. Das Plugin färbt den Fensterrand.
An einem normalen Nachmittag stehen bei mir drei bis fünf PhpStorm- und IntelliJ-Fenster offen, in jedem läuft im Terminal eine Claude-Code-Session. Eines rechnet an einem Refactoring, eines will eine Berechtigung bestätigt haben, eines ist seit zehn Minuten fertig und keiner hat es gemerkt. Von außen sehen alle drei gleich aus. Also klickt man durch — und landet dabei zuverlässig zuerst in dem Fenster, in dem gerade nichts zu tun ist.
Claude Chappe löst genau diesen einen Fall. Das Plugin färbt jedes Projektfenster nach dem Zustand der Sessions, die darin laufen: grün, solange eine Session arbeitet, rot, sobald eine eine Entscheidung braucht oder ihre Runde beendet hat. Gefärbt wird der Fensterrand und auf Wunsch die Statusleiste. Der zweite Teil klingt nach Kosmetik, ist aber der wichtigere: bei überlappenden Fenstern bleibt von einem Hintergrundfenster oft nur dieser eine Streifen sichtbar.
Das Plugin hängt allein an der IntelliJ-Plattform, nicht an einer Sprachunterstützung. Es läuft also in jeder JetBrains-IDE ab 2025.1 — PhpStorm, IntelliJ, WebStorm, PyCharm, GoLand.
Claude Chappe auf GitHub
Open Source, MIT-lizenziert. Kotlin, IntelliJ-Plattform, dazu ein Hook-Script für Claude Code. Im JetBrains Marketplace liegt es noch nicht — bis dahin ./gradlew buildPlugin und die ZIP aus build/distributions/ von Hand installieren.
Wie es funktioniert
Claude Code kann bei bestimmten Ereignissen Shell-Befehle ausführen. Genau daran hängt sich das Plugin: Ein kleines POSIX-Script schreibt bei jedem Ereignis den aktuellen Zustand der Session in eine Datei unter ~/.claude/ide-status/.
// ~/.claude/ide-status/<session-id>.json
{ "session": "…", "cwd": "/pfad/zum/projekt", "state": "working", "ts": 1787047737, "pid": 30037 }
Das Plugin liest dieses Verzeichnis in kurzen Abständen und vergleicht das cwd jeder Session mit dem Basispfad jedes offenen Projekts. Sessions in Unterverzeichnissen zählen zum Projekt darüber, eine Session in apps/api färbt also das Repository-Fenster.
Terminal-Ausgabe wird dabei nicht mitgelesen und die Prozessliste nicht nach laufenden Claude-Instanzen durchsucht. Aus der Prozesstabelle kommt nur die Antwort auf eine einzige Frage: Läuft die PID aus der Statusdatei noch? Wenn nicht, ist die Session abgestürzt, die Datei fliegt raus, und ein totes working kann kein Fenster dauerhaft grün halten.
Sechs Ereignisse registriert der Installer:
| Ereignis | Zustand | |
|---|---|---|
SessionStart | idle | Session existiert, es läuft noch nichts. |
UserPromptSubmit | working | Prompt abgeschickt. |
PostToolUse | working | Ein Tool-Aufruf ist durch. |
Notification | waiting | Claude will eine Entscheidung oder wartet auf Eingabe. |
Stop | idle | Claude ist mit seiner Runde fertig. |
SessionEnd | — | Die Statusdatei wird gelöscht. |
PostToolUse steht mit im Bund, weil sonst ein Fall offen bleibt: Wer einen Berechtigungsdialog bestätigt, schickt damit keinen Prompt ab. Ohne dieses Ereignis bliebe das Fenster rot, obwohl Claude längst weiterarbeitet.
Die Hooks melden Zustände, nicht Farben
Das ist die eine Entscheidung, die den Aufbau prägt. Das Script kennt working, waiting und idle — und sonst nichts. Ob eine fertige Session Aufmerksamkeit verdient, ob sie rot wird, wie rot: alles im Plugin.
Der Grund ist praktischer Natur. Hooks werden beim Start einer Session eingelesen; wer sie ändert, muss jede laufende Session neu starten. Einstellungen im Plugin greifen sofort. Also wandert alles, was man erfahrungsgemäß zweimal umstellt, auf die Plugin-Seite: ob eine beendete Runde überhaupt rot macht (Voreinstellung ja, abschaltbar, wenn Rot den Berechtigungsdialogen vorbehalten bleiben soll), und ob ein Blick ins Fenster dieses Signal wieder löscht.
Der Fokus-Fall ist der, den ich unterschätzt hatte. Ohne ihn bleibt jede fertige Session rot, bis man ihr den nächsten Prompt gibt — nach einer Stunde leuchtet der halbe Bildschirm und sagt nichts mehr aus. Das Fenster, in dem gerade gearbeitet wird, färbt sich deshalb grundsätzlich nicht rot.
Drei kleinere Entscheidungen aus derselben Ecke:
Polling statt Dateiwächter. Im Verzeichnis liegt eine Handvoll winziger Dateien, ein Listing kostet praktisch nichts. Ein Watcher brächte dafür plattformspezifische Fehlerbilder mit, die man dann einzeln nachstellen darf.
Der Rand wird einmal gesetzt, danach wechselt nur die Farbe. Tauscht man stattdessen den Border aus, ändern sich die Insets der Root Pane und das Fenster legt bei jedem Zustandswechsel ein vollständiges Re-Layout hin. Bei einem Stapel offener Projekte sieht man das deutlich.
Beide Pfade werden aufgelöst, bevor sie verglichen werden. Die IDE meldet den Projektpfad mit aufgelösten Symlinks, das Hook-Script schreibt das Arbeitsverzeichnis so, wie die Shell es kennt. Auf macOS reicht /tmp gegen /private/tmp, und ein über einen Link geöffnetes Projekt bleibt farblos. Das war der erste Bugfix nach dem Release.
Fenster stapeln
Dazu gekommen ist Window → Cascade Project Windows: Alle offenen Projektfenster einer IDE landen versetzt auf einem Bildschirm, das dringendste vorn und vollständig sichtbar. Der Stapel sitzt oben und mittig, was auf einem breiten Monitor angenehmer ist als die linke Ecke. Größe und Versatz stehen in den Einstellungen.
Möglich ist das, weil alle Projektfenster einer JetBrains-IDE im selben Prozess leben. Das Plugin setzt sie direkt. Kein Zugriff auf die Bedienungshilfen, kein Window-Manager-Scripting, nichts, was beim nächsten macOS-Update auf Berechtigungen läuft.
Woher der Name kommt
Claude Chappe hat 1792 den optischen Telegrafen gebaut: eine Kette von Türmen mit beweglichen Armen, die vom nächsten Hügel aus ablesbar waren und eine Nachricht in Minuten quer durch Frankreich trugen. Zustand über Entfernung, übermittelt durch nichts als das, was man von weitem sieht. Genau das macht ein gefärbter Fensterrand am anderen Ende eines Stapels von IDEs.
Dass der Vorname passt, war ein angenehmer Zufall.
Grenzen
Ein Fall bleibt bewusst offen: Wer einen Berechtigungsdialog bestätigt und dann ein Tool minutenlang laufen lässt, sitzt so lange vor einem roten Fenster. Claude Code kennt kein Ereignis für den Moment der Freigabe, das nächste Signal ist PostToolUse — und das kommt erst, wenn das Tool zurück ist.
Ansonsten: jq muss da sein, das Hook-Script ist POSIX-Shell und braucht unter Windows Git Bash oder WSL. Sessions, die vor der Installation schon liefen, arbeiten mit ihrer alten Hook-Konfiguration weiter, bis man sie neu startet.
Fazit
Das Plugin ist klein und tut eine Sache. Angefangen hat es damit, dass ich zum wiederholten Mal durch vier Fenster geklickt habe, um das eine zu finden, das auf mich wartete. Seitdem steht die Antwort am Rand.
Der interessantere Teil war nicht die Färbung, sondern die Frage, woher die IDE überhaupt weiß, was in einem Terminal passiert, ohne dass jemand Ausgaben parst. Über die Hooks bekommt Claude Code eine saubere Schnittstelle nach außen — sechs Ereignisse, eine kleine Datei, fertig. Das lässt sich für einiges mehr verwenden als für Farben.
Call to Action
Claude Chappe ist Open Source und liegt auf GitHub: https://github.com/McGo/claude-chappe
Fehlerberichte und Pull Requests sind willkommen. Und wenn Sie Claude Code im Team einsetzen und sich fragen, wo die sinnvollen Andockpunkte zwischen Agenten, IDE und bestehender Toolchain liegen: melden Sie sich gern.