Kurzfassung
T3 Code bündelt Coding-Agenten wie Codex und Claude Code in einer gemeinsamen Desktop-, Web- und Mobiloberfläche. Du organisierst Aufgaben, prüfst Änderungen und steuerst Freigaben, ohne für jedes Backend eine andere Oberfläche zu öffnen. Die vier angebotenen Berechtigungsmodi bedeuten aber nicht überall dasselbe: Konten, Quoten, native Sitzungen und Sicherheitsfunktionen bleiben backendabhängig. Der Nutzen liegt in der gemeinsamen Bedienung, nicht in nachweislich besserem Code. Starte deshalb mit einem Provider, eingeschränkten Rechten und einer kleinen, überprüfbaren Änderung.
Bezugsstand ist v0.1.7, veröffentlicht am 4. November 2026. Der Artikel beruht auf Dokumentation und statischer Quellcodeprüfung, nicht auf einer eigenen Installation oder einem Produkttest.
Was steuert T3 Code und was bleibt beim Harness?
T3 Code ist eine gemeinsame Arbeitsoberfläche über vorhandenen Agent Harnesses. Ein AI Harness organisiert unter anderem Werkzeugausführung, Kontext und Sitzungszustand um ein Modell herum. T3 Code ergänzt darüber Projekte, Threads, Dateiansichten, Git-Aktionen und den Zugang von anderen Geräten.
Die Architektur lässt sich vereinfacht so lesen: Bediengerät → T3-Server auf dem ausführenden Host → Provider beziehungsweise Harness → Modell. Der Server kann auf deinem Rechner oder einer entfernten Maschine laufen. Die Installationsdokumentation ordnet Einrichtung und Anmeldung ausdrücklich dieser ausführenden Umgebung zu, nicht dem Handy oder Browser davor.
| Ebene | Aufgabe | Was dadurch nicht vereinheitlicht wird |
|---|---|---|
| T3-Code-Oberfläche und Server | Projekte, Threads, Datei- und Diffansichten, Steuerung der Provider | Keine Garantie identischer Backendfunktionen |
| Provider/Harness | Werkzeugausführung, native Sitzungen, Modellanbindung und backendseitige Kontrollen | Konten, Quoten und Berechtigungsverhalten bleiben unterschiedlich |
| Host | Projektdateien, Prozesse, Zugangsdaten und Betriebssystemrechte | Muss verfügbar sein; getrennte Threads ersetzen keine Hostisolation |
Es gibt echte Provideradapter, nicht bloß eingebettete Terminalfenster: Codex wird über seinen App Server angebunden, Claude über das Agent SDK. Weitere Integrationen umfassen beispielsweise Cursor, OpenCode und Pi; zusätzlich existiert ein ACP-Registry-Treiber. Das zeigt die Providerregistrierung im gebundenen Quellcode. Eine starre Gesamtzahl wäre irreführend, weil ein generischer Treiber nicht einem einzelnen gleichwertig unterstützten Agenten entspricht.
| Kerndatum | Einordnung |
|---|---|
| Lizenz und Sprache | MIT, überwiegend TypeScript laut Repository-Metadaten |
| Betrachtetes Release | v0.1.7 |
| Aufmerksamkeit | Rund 45.000 GitHub-Sterne im Repository, Snapshot vom 4. November 2026 |
| Einstieg | Desktop-App oder separater Server; npx setzt Node.js voraus |
| Modellkosten | Eigene Providerzugänge; kostenlose Oberfläche bedeutet keine kostenlose Inferenz |
Sterne messen Aufmerksamkeit, nicht Codequalität oder Zuverlässigkeit.
Wie startest du sinnvoll mit einem Agenten?
Für den Einstieg ist die Desktop-App der übersichtlichste Weg. Lade das passende Paket über die offizielle Projektseite beziehungsweise die Release-Seite. Die Desktop-App bringt ihre Serverruntime mit. Voraussetzungen für Entwicklerbuilds sind deshalb keine allgemeinen Installationsvoraussetzungen; der alternative npx-Start benötigt dagegen Node.js, wie der Installationsguide erklärt.
Ein konservativer erster Ablauf:
- Umgebung wählen: Entscheide, auf welcher Maschine Projekt und Agent tatsächlich arbeiten sollen. Füge dort ein kleines Git-Projekt hinzu.
- Einen Provider einrichten: Öffne
Settings → Providers, wähle die Umgebung und aktiviere zunächst nur das gewünschte Backend. Bei Claude gehört die CLI-Anmeldung auf diesen Host. Codex bietet zusätzlich eine direkte ChatGPT-Anbindung; Antigravity dokumentiert eine Anmeldung aus den Providereinstellungen ohne separate CLI. - Freigaben vor dem Start prüfen: Setze den neuen Thread bewusst auf
Supervisedund prüfe die Unterstützung deines Backends. Übernimm nicht ungeprüft den voreingestellten Modus. - Arbeitsstand trennen: Verwende für die Änderung einen eigenen Branch beziehungsweise Worktree. Starte noch keine konkurrierenden Aufgaben auf denselben Dateien.
- Ergebnis abnehmen: Lies den vollständigen Branch-Diff und kontrolliere die ausgeführten Tests. Erst danach übernimmst du die Änderung.
Die Bedienwege stammen aus Installation, Berechtigungsdokumentation und Source-Control-Guide. Die Reihenfolge ist eine Empfehlung, kein von mir durchgeführter Test.
Ein selbst formulierter erster Auftrag:
Ergänze Regressionstests für die vorhandene Eingabevalidierung. Beschränke Änderungen auf das betroffene Modul und seine Tests. Zeige anschließend die geänderten Dateien, die tatsächlich ausgeführten Testbefehle und alle offenen Fehler. Keine Veröffentlichung und kein Deployment.
T3 Code ist dabei nicht auf Chat und Diffanzeige beschränkt. Der Dateieditor erlaubt auch manuelle Änderungen an beschreibbaren Workspace-Dateien, sofern der Client die nötigen Rechte hat. Das belegt keinen vollständigen Ersatz für deine bisherige IDE.
Warum bedeuten gleiche Freigabemodi nicht gleiche Kontrolle?
Die wichtigste Einstellung sitzt vor dem ersten Auftrag: Der initiale T3-Standard für neue reguläre Threads ist Full access; Nutzer-, Projekt- oder Hostvorgaben können ihn ändern oder begrenzen. Unterstützt ein Provider den gewählten Modus nicht, fällt der aktive Ausführungspfad auf Supervised zurück. Bestehende Threads behalten ihre gewählten Rechte. Den Standard änderst du unter Settings → Threads → New threads → Permissions, den einzelnen Thread über die Berechtigungsauswahl am Eingabefeld beziehungsweise im Modellpicker.
Die Dokumentation der Berechtigungsmodi unterscheidet:
| Modus | Grundidee | Entscheidende Einschränkung |
|---|---|---|
| Supervised | Für Befehle und Dateiänderungen Freigaben einholen | Konkrete Unterstützung hängt vom Adapter ab; manche Leseaktionen laufen ohne Rückfrage |
| Auto-accept edits | Dateiänderungen automatisch erlauben | Andere Aktionen können weiter eine Freigabe benötigen |
| Auto | Je nach Adapter automatische Prüfung oder automatische Zustimmung | Bei ACP-Registry-Anfragen kann T3 automatisch zustimmen; die nativen Agentenregeln bleiben separat |
| Full access | Befehle und Änderungen ohne reguläre Freigabedialoge erlauben | Backendregeln und verwaltete Hostrichtlinien können weiter begrenzen |
Bei ACP-Registry-Agenten genehmigt T3 im Modus Auto deren Freigabeanfragen automatisch; das ist keine eigene Sicherheitsprüfung.
Das sind keine kosmetischen Labels. Im Codex-Adapter setzt der unveränderte Full-access-Pfad approvalPolicy: never und dangerFullAccess. Hier wird also gerade keine eingeschränkte Workspace-Sandbox angefordert.
Umgekehrt ist Supervised keine universelle Zusage menschlicher Einzelgenehmigungen. Der Cursor-Adapter deklariert interaktive Freigaben für Befehle, Dateilesen und Dateiänderungen als nicht unterstützt. Wähle deshalb einen konservativen Modus und prüfe zusätzlich das konkrete Backend.
Worktrees sind keine Sandbox
Ein Worktree trennt Arbeitsverzeichnis und Branch für eine Aufgabe. Er begrenzt nicht automatisch Prozessrechte, Secrets oder Netzwerkzugriffe. Der Git-Anlagepfad erstellt eine zusätzliche Git-Arbeitskopie, keinen Sicherheitscontainer.
Native Harness-Sandboxes und zusätzliche Hostisolation sind andere Schutzebenen. Für sensible Projekte reicht deshalb weder ein eigener Thread noch ein eigener Worktree als Sicherheitskonzept.
Was bleibt bei Agentenwechsel und Neustart erhalten?
Ein sichtbarer T3-Thread und eine native Providersitzung sind nicht dasselbe. Der implementierte Übergangspfad unterscheidet Wiederverwendung, Modellwechsel innerhalb der Sitzung, Neustart mit Wiederaufnahme und eine neue Sitzung mit Kontextübergabe. Nicht verfügbare Ziele können abgewiesen werden.
Beim Wechsel auf ein inkompatibles Backend entsteht somit kein gemeinsames natives Gedächtnis. T3 kann ausgewählte bisherige Inhalte als Übergabekontext bereitstellen. Der Handoff-Code wählt Historie innerhalb eines Budgets aus und erfasst ausgelassene Elemente. Eine verlustfreie Migration sämtlicher Informationen oder laufender Fremdprozesse ist damit nicht belegt.
Ähnlich beim Neustart: Gespeicherte Gespräche sind keine weiterlaufenden Prozesse. Laut Update-Dokumentation ist die Fortsetzung unterstützter Threads standardmäßig eingeschaltet. T3 Code muss auf dem Host aber wieder starten; ohne gespeicherten Providerzustand kann eine neue Nachricht erforderlich sein. Wartet ein Thread auf Freigabe, Antwort oder Secret, wird er nicht blind fortgesetzt. Terminalbefehle und Entwicklungsserver können unterbrochen werden.
Praktisch heißt das: Halte Ziel, offene Schritte und Testergebnisse zusätzlich im Projekt fest. Ein erreichbarer Verlauf erleichtert die Wiederaufnahme, ersetzt aber keine Prüfung des tatsächlichen Arbeitsstands.
Welche Grenzen gelten bei Remotezugriff und Daten?
Remotezugriff verlagert die Bedienung, nicht automatisch die Ausführung. Die Remote-Dokumentation beschreibt mehrere Wege:
| Verbindung | Nutzen | Abhängigkeit |
|---|---|---|
| T3 Connect | Zugriff ohne eigene Routerweiterleitung | T3-Konto, Relay und Cloudflare-Tunnel |
| Direktes Pairing über LAN oder privates Netz | Verbindung zum erreichbaren Host | Passende Adresse, Netzkonfiguration und Clientfreigabe |
| Desktopverwaltetes SSH | Serverzugriff über die Desktop-App | SSH-Zugang und korrekt eingerichteter Remotehost |
Der ausführende Host muss laufen und erreichbar bleiben. Ein zugeklappter Laptop hilft nur, wenn er dabei weiterarbeitet; auf einer ausgeschalteten Maschine rechnet kein Agent weiter.
Drei Berechtigungsebenen darfst du nicht vermischen: Der Agentenmodus regelt Backendaktionen, die Clientfreigabe erlaubt direkte Bedienaktionen, und externe MCP-Agenten erhalten eine eigene Autorisierung. Laut Outside-Agent-Guide ist für diesen externen MCP-Zugang Read only voreingestellt. Das ist ein anderer Default als Full access bei regulären neuen Threads.
Pairing-URLs gehören wie Passwörter behandelt. Ein widerrufener ungenutzter Link verhindert neue Kopplungen, entzieht bereits gekoppelten Geräten aber nicht deren bestehende Sitzung. Dafür musst du die betreffende Clientsitzung widerrufen. Unbeschränktes Pairing kann weitreichende Rechte einschließlich Zugriffsverwaltung vergeben; Details stehen unter Manage or revoke access.
Auch der lokale Ausführungsort ist kein Datenschutzversprechen. Modellanfragen können zum Provider gehen; T3 Connect nutzt Cloudflare als Transport. Zusätzlich ist Produkttelemetrie standardmäßig aktiviert. Die Telemetriedokumentation nennt unter anderem Provider, Modell, Berechtigungsmodus, Dauer und verfügbare Tokenzahlen sowie gehashte Account- oder Installationskennungen. Das ist verknüpfbar, nicht streng anonym.
T3CODE_TELEMETRY_ENABLED=false im Serverenvironment deaktiviert die serverseitige Produkttelemetrie und das serverseitige Relaytracing. Die Browser-App liest diese Servervariable nicht; mobile Crashreports haben einen eigenen Schalter. Das ist kein Abschalter für sämtliche Modell- oder Pushverkehre. Die optionale Agent-Awareness-Funktion kann außerdem Projekt- und Threadtitel sowie Statusinformationen an das Relay übertragen. Prüfe diese Datenwege bei vertraulichen Projekten getrennt.
Für wen lohnt sich die zusätzliche Oberfläche?
Der sinnvolle Vergleich ist nicht, welcher Agent dadurch intelligenter wird, sondern welchen Arbeitsplatz du brauchst:
| Deine Arbeitsweise | Einordnung |
|---|---|
| Du wechselst regelmäßig zwischen mehreren Harnesses | T3 Code bündelt Bedienung und Übersicht, ohne deren Konten und Grenzen aufzulösen |
| Du willst dieselbe Hostumgebung von mehreren Geräten steuern | Remotezugriff kann passen; Hostbetrieb und Zugangsschutz kommen hinzu |
| Du arbeitest effizient mit einer CLI, Git und deiner IDE | Eine weitere Steuerungsschicht ist nicht automatisch ein Fortschritt |
| Du suchst vor allem einen Pi-zentrierten Arbeitsplatz | ThinkRail verfolgt einen anderen, enger gebundenen Ansatz |
Welche Einschränkungen bleiben?
Die zusätzliche Schicht bringt eigenen Betriebsaufwand. Client und Server müssen laut Update-Guide ein kompatibles Orchestrierungsprotokoll sprechen; Provider benötigen ebenfalls passende Versionen. Native Konfigurationen und Fähigkeiten werden nicht automatisch vollständig übernommen.
Für bessere Codequalität, geringere Gesamtkosten oder höhere Zuverlässigkeit liefert diese Dokumentations- und Codeanalyse keinen Messnachweis. Prüfe deshalb zuerst, ob Übersicht und Review deinen konkreten Ablauf verbessern, bevor du mehr Parallelität einführst.
FAQ: Häufig gestellte Fragen zu T3 Code
Ist T3 Code ein eigenes Modell oder ein neuer Coding-Agent?
Nein. Es ist eine gemeinsame Arbeits- und Steuerungsoberfläche über vorhandenen Agent Harnesses. Modellfähigkeiten und viele Laufzeiteigenschaften stammen weiterhin vom gewählten Backend.
Ist T3 Code kostenlos?
Die Software steht unter MIT-Lizenz. Providerabonnements beziehungsweise Modellkosten bleiben separat; optionale Remote-Dienste und deren aktuelle Grenzen solltest du zusätzlich prüfen.
Macht ein Worktree Full access sicher?
Nein. Ein Worktree trennt Git-Arbeitsstände, nicht Betriebssystemrechte. Welche Sandbox und Freigaben tatsächlich greifen, hängt von Backend, Modus und Hostkonfiguration ab.
Läuft eine Aufgabe bei geschlossenem Laptop weiter?
Nur wenn der ausführende Host weiterläuft und T3 Code dort aktiv bleibt. Ein anderes Bediengerät ersetzt keinen ausgeschalteten oder schlafenden Ausführungsrechner.
Kann ein anderer Agent dieselbe Sitzung übernehmen?
T3 kann je nach Kompatibilität eine native Sitzung fortsetzen oder eine neue Sitzung mit ausgewähltem Übergabekontext anlegen. Das ist keine verlustfreie Übertragung des gesamten nativen Zustands.


Fazit
T3 Code lohnt einen begrenzten Versuch, wenn du mehrere Coding-Harnesses und deren Änderungen in einer gemeinsamen Oberfläche organisieren willst. Starte mit einem Provider, eingeschränkten Rechten und einer kleinen Aufgabe, deren Diff und Tests du selbst abnimmst. Erwarte vereinheitlichte Bedienung, nicht vereinheitlichte Sicherheit oder nachweislich besseren Code. Die Grundlagen erklärt der AI-Harness-Guide; einen anders zugeschnittenen Agentenarbeitsplatz zeigt ThinkRail.
Quellen
Dokumentations- und Quellcodestand: Release v0.1.7 vom 4. November 2026. Die verwendeten Codebelege sind an den Commit des Tags gebunden. Der GitHub-Sterne-Wert ist ein datierter Snapshot, keine fortlaufend aktualisierte Kennzahl.
Primärquellen
- Projekt: README, Repository-Metadaten und Downloads.
- Einstieg und Betrieb: Installation und Provider, Source Control und Updates und Restartfortsetzung.
- Kontrollgrenzen: Berechtigungsmodi, Remotezugriff und Pairing und externe MCP-Agenten.
- Statische Codebelege: Codex-Berechtigungen, Cursor-Approvalgrenzen, Providerwechsel und budgetierte Kontextübergabe.
- Datenwege: Telemetriedokumentation, aktivierter Telemetriestandard und Activity-Datenstruktur.
Synthese und Evidenzgrenzen
- Recherche-Notebook in NotebookLM: quellengebundene Synthese, kein Ersatz für Originalbelege; Google kann eine Anmeldung verlangen.
- Keine eigenen Laufzeittests und keine unabhängigen Produktivitäts-, Kosten- oder Zuverlässigkeitsmessungen für diesen Artikel.