CLODEx: eine lokal ausgerichtete agentische IDE mit Review-Pflicht
Local-First, Zero-Trust-Agenten-IDE für überprüfbare autonome Softwareentwicklung.
Auf einen Blick
- Was ist das?
- CLODEx führt Code, Git, Terminal, Browser, Modelle und MCP-Werkzeuge in einem dauerhaften Arbeitsbereich zusammen und verlangt vor heiklen Aktionen Genehmigung. Der Text ordnet die Technical Preview, die Sicherheitsoberflächen, den Free Product Contract und die AGPL-3.0-Lizenz ein.
- Für wen ist es gedacht?
- CLODEx richtet sich an Entwickler, die länger laufende Engineering-Aufgaben in einer lokalen IDE behalten und jeden Schritt des Agenten kontrolliert freigeben wollen; das durchsuchbare Aufgabenmodell und die Review-Oberflächen sind der Unterschied zu einem Chat-Tool. Wer unsignierte Testpakete umgehen will, sollte selbst aus dem gepinnten Quelltext d2dd2b63 bauen und die SHA-256-Prüfsummen zuordnen.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 5 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
CLODEx und das Modell der dauerhaften Aufgabe
CLODEx ist eine Open-Source, lokal ausgerichtete agentische IDE für langwierige Engineering-Arbeit. Das README formuliert den Unterschied zu gewöhnlichen Chat-Oberflächen: Die meisten KI-Programmierschnittstellen seien auf die nächste Nachricht optimiert, echte Engineering-Arbeit sei aber lang. Sie umfasst das Verstehen eines Repositories, das Planen einer Änderung, das Bearbeiten mehrerer Dateien, das Ausführen von Befehlen, das Prüfen der Anwendung, das Reviewen des Diffs, die Erholung von Fehlern und das Fortführen am nächsten Tag.
CLODEx behandelt diese Arbeit als dauerhafte Aufgabe. Code, Git, Terminal, Browser, Modelle und MCP-Tools bleiben in einem Arbeitsbereich beisammen, mit Genehmigungs- und Review-Oberflächen für heikle Aktionen. Der Grundsatz im README lautet: Modellausgabe ist Eingabe, nicht Autorität. Genau dieser Satz erklärt, warum der Ablauf auf Review angelegt ist und ein Chat-Protokoll nur als Nebenrolle dient.
Die Technical Preview Community Observed 21
Die aktuelle kostenlose Vorschau heißt Community Observed 21 und ist als unveränderlicher Prerelease v1.16.0-communityobserved21 vom 29. Juli 2026 veröffentlicht. Das README legt die Herkunft offen: gebaut aus dem exakten kanonischen Quelltext d2dd2b63077c67255d60b8ab53f5c3c0995c7f84 durch den GitHub-Actions-Lauf 30483341383, geprüft gegen die erzwungenen Gates für den kostenlosen und den verpackten Umfang.
Die Pakete sind noch nicht signiert oder nur ad-hoc signiert: macOS ist nicht notarisiert, Windows nicht mit Authenticode signiert, Linux trägt keine Anbietersignatur. Das README schreibt vor, SHA-256 zu prüfen und den Review-Flow des Betriebssystems zu nutzen. Ein Check for Updates unter Settings und About führt eine manuelle, fail-closed Abfrage aus und kann eine neuere Community-Vorschauseite im externen Browser öffnen; automatische Updates lädt das Programm nicht herunter.
Berechtigung, Genehmigung und Review als sichtbare Oberflächen
Der Ablauf ist im README als Kette dargestellt: Anfrage des Entwicklers, Vorschlag des Agenten, Berechtigungs- und Genehmigungsprüfung, Ausführung lokaler Werkzeuge, Rückgabe von Diffs, Ausgaben, Artefakten und Aufgabenhistorie zum Review. Der öffentliche Quelltext enthält explizite Oberflächen für Berechtigung, Genehmigung, Diff und Review; das Sicherheits- und Datenmodell liegt in docs/developer/security-and-data.md.
Aufgabenstatus und Desktop-Werkzeuge sind standardmäßig lokal; Netzwerkzugriff nutzen nur Funktionen, die der Nutzer wählt. Die Anmeldung über CLODEx.xyz setzt auf State, PKCE S256 und einen exakten Loopback-Callback; Bearer-Tokens landen nicht in der Callback-URL, Anmeldedaten liegen im geschützten Speicherpfad der Anwendung statt im lokalen Speicher des Renderers. Telemetrie beginnt erst nach einer Erlaubnis- oder Ablehn-Entscheidung beim ersten Start und bleibt laut Community-Vertrag auf pseudonyme Ereignisse beschränkt, ohne Prompts, Nachrichten, Quellcode, Befehle oder Schlüssel.
Vier Wege, Modelle anzubinden, von Ollama bis BYOK
Modelle lassen sich auf vier Wegen anbinden: mit einem CLODEx-Konto über CLODEx.xyz, mit einem eigenen Schlüssel für unterstützte Anbieter, mit einem benutzerdefinierten OpenAI-kompatiblen Endpunkt oder mit einer lokalen Ollama-Instanz, üblicherweise unter http://localhost:11434. Für eigene Schlüssel und eigene Endpunkte bleiben Anbieterbedingungen, Verfügbarkeit und Kosten laut README Sache zwischen Nutzer und Anbieter.
Wer das Projekt öffentlich nutzt, dem rät das README, keine API-Schlüssel, Tokens, privaten Quellcode oder unredigierten Protokolle in Issues zu posten. Die vier Pfade ergeben zusammen ein Modell, in dem weder das Konto noch ein bestimmter Anbieter zur Voraussetzung wird: Selbst die vollständig lokale Variante mit Ollama ist vorgesehen, und genau das entspricht der lokalen Ausrichtung des Projekts.
Der kostenlose Produktumfang laut Free Product Contract
Der kostenlose Produktumfang ist im README tabellarisch gegliedert: dauerhafte Aufgaben mit durchsuchbarer Historie und Wiederanlauf nach Absturz, Code und Review mit Pending Edits und zeilengenauen Diffs, Terminal und Browser mit lokalen Ports und eingebettetem Browsing, Modelle mit den vier Pfaden, MCP mit stdio- und Remote-Servern sowie OAuth, Kontozugriff, Sprache mit Englisch und Russisch in Beta sowie Verteilung über Testpakete für macOS, Windows, Debian/Ubuntu und Fedora/RHEL.
Die Grenze zwischen dem freien und dem verwalteten Umfang wird durch einen Free Product Contract in docs/COMMUNITY_FREE_PRODUCT_CONTRACT.md festgeschrieben, und CI prüft im Repository, dass diese Grenze fail-closed bleibt. Der Community-Observed-Vertrag sagt ausdrücklich, dass Prompts, Nachrichten, Quellcode, Befehle, Pfade, URLs, API-Schlüssel, Tool-Argumente und weitere Inhalte nicht telemetriert werden.
Aus dem Quelltext bauen: Node.js, pnpm und die Start-Sequenz
Wer aus dem Quelltext bauen will, braucht laut README Node.js 22.23.1, pnpm 10.30.3, Git sowie macOS, Linux oder Windows. Die Reihenfolge: Repository klonen, Corepack aktivieren und pnpm in der festgelegten Version bereitstellen, .env.example nach .env und .env.dev kopieren, pnpm install --frozen-lockfile ausführen, danach pnpm build:packages und pnpm --dir apps/browser start:fast.
Vor einem Pull-Request sind pnpm check, pnpm typecheck, pnpm test und pnpm security:secrets vorgesehen; Beiträge sollen begrenzt, testbar und reviewbar sein und nach dem DCO des Repositories signiert werden. Diese Sequenz ist konkret überprüfbar und ersetzt jede allgemeine Build-Empfehlung: Wer die IDE selbst baut, kennt danach die genaue Versionskette seiner Umgebung.
Herkunft von Stagewise, AGPL-3.0 und was der Vertrag belegt
CLODEx beginnt als modifizierte Version der Open-Source-Basis Stagewise und ist seitdem eigenständig gepflegt; die Beziehung zwischen beiden ist in der Dokumentation CLODEx vs Stagewise festgehalten, inklusive Upstream-Basis-Commit, reproduzierbarer Diff-Methode und weitergeführter abgeleiteter Bereiche. Das Projekt ist weder mit Stagewise verbunden noch von ihm unterstützt, und Third-Party-Hinweise bewahren die Upstream-Urheberrechte.
Veröffentlicht wird unter der GNU Affero General Public License v3.0. Sie erlaubt Kopieren, Verteilen und Modifizieren und verlangt, dass modifizierte Versionen, die auf einem Netzwerkserver laufen, ihren Quellcode den Nutzern zugänglich machen; eine Gewährleistung übernimmt der Lizenztext nicht. Was ein Validierungsbericht tatsächlich belegt, ist laut README nur das, was er geprüft hat: Eine Vorschau ist kein stabiles Produkt.
Redaktionelles Fazit
CLODEx richtet sich an Entwickler, die länger laufende Engineering-Aufgaben in einer lokalen IDE behalten und jeden Schritt des Agenten kontrolliert freigeben wollen; das durchsuchbare Aufgabenmodell und die Review-Oberflächen sind der Unterschied zu einem Chat-Tool. Wer unsignierte Testpakete umgehen will, sollte selbst aus dem gepinnten Quelltext d2dd2b63 bauen und die SHA-256-Prüfsummen zuordnen. Vor der Einführung ist ein Lauf aus dem Free Product Contract gegen die eigene Umgebung sinnvoll, denn das README verspricht kein stabiles Produkt, und AGPL-3.0 stellt Bedingungen für Netzwerk-Einsatz und Weitergabe.
Community-Notizen