OpenCode behebt den Fehler, während Sie in Ihrem Arbeitsverzeichnis weiterarbeiten

Sie haben eine halb fertige Änderung in Ihrem Checkout, als jemand einen Fehler im Datumsparser meldet. Sie möchten Ihre Dateien weiterbearbeiten und dem Programmieragenten eine eigene Aufgabe geben. Sobald beide dasselbe Verzeichnis ändern, lässt sich selbst ein kleiner Korrekturvorschlag nur schwer von Ihrer laufenden Arbeit trennen.

Am 6. November hat OpenCode 2.2.6 eine Worktree-Option für skriptgesteuerte Kommandozeilenläufe eingeführt. OpenCode ist ein quelloffener Programmieragent mit interaktivem Terminal und einem separaten Befehl für Prompts aus Skripten. Mit der neuen Option kann ein Skript OpenCode in einem eigenen Git-Worktree starten, ihn optional benennen und das ursprüngliche Arbeitsverzeichnis freihalten. Dieselbe Version ergänzt eine freiwillige Freigabe für passende Verbindungen des Model Context Protocol (MCP). Das wirft vor dem Start zwei Fragen auf. Welche Dateien darf der Agent ändern und welche Dienste darf er nutzen? OpenCode v2.2.6 · OpenCode-CLI-Dokumentation

Eine brauchbare Einrichtung verbindet eine eng begrenzte Aufgabe mit einem bekannten Ausgangspunkt, einem Ort für die Prüfung und ausdrücklichen Berechtigungen für alles außerhalb des Projekts.

Der Terminal-Screenshot des OpenCode-Projekts zeigt einen Patch und eine Sitzung. Das Bildmaterial der markierten Version zeigt die Terminaloberfläche. Der MIT-Lizenzhinweis liegt bei. Telli.sh hat den Screenshot skaliert und einen Rand ergänzt.

Ein separates Verzeichnis liefert einen nachvollziehbaren Diff

Ein Git-Worktree gibt jeder Aufgabe eigene Arbeitsdateien und einen eigenen Index. Eigene Illustration von Telli.sh.

Git-Worktrees verbinden mehrere Arbeitsverzeichnisse mit einem Repository. Jedes verknüpfte Verzeichnis hat eigene Arbeitsdateien, einen eigenen Index und einen eigenen ausgecheckten Stand. Der größte Teil der Repository-Daten wird geteilt. So können Sie den Patch des Agenten separat prüfen, während die ursprünglichen Änderungen dort bleiben, wo Sie sie bearbeitet haben. Zugleich ändert sich, welchen Quellcode der Agent sieht. Nicht eingecheckte Änderungen des ersten Verzeichnisses erscheinen nicht im zweiten Checkout, nur weil beide zum selben Repository gehören. Git-Dokumentation zu Worktrees

OpenCodes Version vom 6. November dokumentiert drei Schreibweisen. Verwenden Sie opencode run -w oder opencode run --worktree für einen neuen Worktree und --worktree=<name>, um ihn zu benennen. Die Option lässt sich laut Version nicht mit --continue oder --session kombinieren. Ein neuer Lauf braucht einen eigenen Startkontext. Wenn an einem Fehlerbericht bereits eine lange Unterhaltung hängt, übernehmen Sie die relevanten Reproduktionsschritte und das erwartete Ergebnis in den neuen Prompt. OpenCode v2.2.6 · Implementierung und Beispiele der Worktree-Option

Betrachten Sie das separate Verzeichnis als Ort für die Prüfung. Notieren Sie vorab Branch und Commit, auf denen der Agent arbeiten soll. Sehen Sie danach Commit und Status seines Worktrees an. Hängt ein Test von einer nicht versionierten Testdatei oder einer Änderung ab, die nur im Editor des Entwicklers existiert, erklärt der Unterschied im Ausgangsstand scheinbar widersprüchliche Ergebnisse. Ein Patch kann für den älteren Stand korrekt sein und trotzdem nicht zu dem Branch passen, den Sie ausliefern wollen.

Testen Sie erst eine kleine Änderung

Beginnen Sie in einem eigenen Repository mit einer klar umrissenen Aufgabe. Ein fehlgeschlagener Schalttagstest eignet sich besser als ein breit angelegtes Upgrade, weil das erwartete Ergebnis leicht zu prüfen ist. Ähnlich eng wäre die Korrektur eines veralteten Navigationslinks mit einem Routentest. Beschreiben Sie jeweils konkret, welches Verhalten sich ändern soll und wie Sie es überprüfen werden.

1. Halten Sie den Ausgangszustand fest. Führen Sie im aktuellen Verzeichnis git status --short und git rev-parse HEAD aus. Bewahren Sie die Ausgabe beim Fehlerbericht auf. Gibt es bereits einen erfolgreichen Ausgangstest, notieren Sie den Aufruf. Bestätigen Sie mit opencode --version, dass Ihre Version das neue Flag unterstützt. OpenCode v2.2.6

2. Geben Sie dem Agenten eine Aufgabe in einem benannten Worktree. Nehmen Sie Reproduktion und gezielten Test in den Prompt auf. Das Beispiel verwendet einen fiktiven Datumsparser und setzt einen entsprechenden Test im Repository voraus. Nicht eingecheckte Änderungen lassen sich leicht prüfen. Strengere Grenzen setzen Sie über Berechtigungen und Ausführungsumgebung.

   ShellIn Terminal ausführen

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. Ermitteln Sie das neue Verzeichnis vor der Prüfung. Führen Sie im ursprünglichen Repository git worktree list aus und verwenden Sie den ausgegebenen Pfad. Prüfen Sie dort git status --short, git diff und git diff --cached. Der letzte Befehl ist wichtig, wenn der Agent Änderungen zum Commit vorgemerkt hat. Prüfen Sie nicht versionierte Dateien separat. Führen Sie die gezielten Tests selbst im Agentenverzeichnis aus. Prüfen Sie, ob sie sowohl den 29. Februar eines Schaltjahrs als auch ein Jahr mit ungültigem Schalttag abdecken. Git-Dokumentation zu Worktrees

4. Übernehmen Sie nur geprüfte Arbeit. Lassen Sie die vorgeschlagene Änderung getrennt, bis sich ein geprüfter Commit oder Patch auf den vorgesehenen Branch anwenden lässt. Prüfen Sie erneut den Status des ursprünglichen Verzeichnisses. Behalten Sie den Agenten-Worktree, bis alle benötigten Informationen gesichert sind und keine zu bewahrenden Änderungen mehr darin liegen. Die Worktree-Liste zeigt, welches Verzeichnis zu welcher Aufgabe gehört. Git-Dokumentation zu Worktrees

Das Muster hilft auch bei zwei unabhängigen Fehlern. Geben Sie jedem einen kleinen Umfang und vergleichen Sie beide Diffs vor der Integration. Die getrennten Worktrees halten die ungestagten Teständerungen eines Agenten aus dem anderen Verzeichnis. Beim Zusammenführen auf denselben Branch kann es trotzdem Konflikte geben, besonders bei einer gemeinsamen Hilfsfunktion. Integration und abschließende Regression gehören weiterhin zur normalen Prüfung.

Entscheiden Sie, wer außerhalb des Repositorys was darf

Zwei Worktrees können unter demselben Betriebssystemkonto laufen. Sie können dieselbe Umgebung, dieselben Zugangsdaten-Hilfsprogramme und dasselbe Netz erreichen. Die neue Option bestimmt den Startort und trennt alltägliche Änderungen. Wenn die Aufgabe stärkere Grenzen braucht, setzen Sie eigene Konto- oder Laufzeitbeschränkungen. Eine Freigabeabfrage steuert Werkzeuge, die sie beachten. Das Betriebssystem oder die Ausführungsumgebung bestimmt, was der Prozess insgesamt erreichen kann.

Der Ort der Änderungen, Freigaben für Werkzeuge und Zugriffe der Laufzeit sind getrennt. Eigene Illustration von Telli.sh.

Die V2-Dokumentation beschreibt geordnete Berechtigungsregeln für einzelne Aktionen. Dazu gehören allow, ask und deny, wobei die letzte passende Regel gewinnt. Ein offizielles Beispiel fragt vor Shellbefehlen, erlaubt danach übliche Prüfkommandos und verweigert Pushes. Soll der Lauf ohne anwesende Freigabeperson starten, testen Sie das Verhalten einer ask-Regel in diesem Ablauf, bevor Sie ihn wiederholen lassen. Konfigurieren Sie klare Verbote und verwenden Sie kurzlebige, eng begrenzte Zugangsdaten für Dienste, die der Lauf tatsächlich braucht. OpenCode-Dokumentation zu Berechtigungen

Eine reine Dokumentationsaufgabe eignet sich zum Testen dieser Ebenen. Erlauben Sie dem Agenten, einen Abschnitt eines Beispielprojekts zu ändern. Geben Sie ihm einen zugelassenen Anbieter und keine produktiven Zugangsdaten. Prüfen Sie nach dem Skriptlauf, ob der Patch nur die erwartete Datei ändert. Braucht eine spätere Automatisierung einen Remote-Zugriff oder ein Ticketsystem, geben Sie jeder Fähigkeit einen konkreten Zweck und prüfen Sie ihre Rechte separat.

Eine geteilte Verbindung passt, wenn die Projekte dieselben Zugriffsgrenzen haben

MCP erlaubt einem Agenten, Werkzeuge anderer Programme zu verwenden, etwa eine Dokumentensuche oder ein Ticketsystem. In der Version vom 6. November lässt pool: true Verzeichnisse unter demselben OpenCode-Server eine Verbindung wiederverwenden, wenn die relevanten Einstellungen übereinstimmen. Die offizielle V2-Dokumentation nennt dafür die Protokollrevision 2026-07-28. Handelt der Server eine ältere Revision aus, bleiben die Verbindungen getrennt. Übereinstimmung bedeutet mehr als dieselbe Adresse. Remote-Einstellungen und authentifizierte Konten müssen zusammenpassen. Bei einem lokalen Server zählen auch Befehl, Umgebung und Arbeitsverzeichnis. OpenCode v2.2.6 · Dokumentation zu geteilten MCP-Verbindungen

Denken Sie an zwei Worktrees, die mit demselben Konto auf denselben internen Dokumentendienst zugreifen. Teilen kann doppelte Einrichtung sparen, wenn der Dienst die betreffende Revision unterstützt. Bestätigen Sie zuerst, dass beide Verzeichnisse dasselbe Material sehen dürfen und die Integration nur benötigte Funktionen bietet. Braucht ein Worktree nur öffentliche Dokumente und kann der andere interne Tickets öffnen, bleiben getrennte Verbindungen leichter zu prüfen.

Ein lokaler Server kann von seinem Arbeitsverzeichnis abhängen. Ein Prozess je Projektordner kann anderen lokalen Kontext sehen, auch wenn der Befehl identisch ist. Laut OpenCode ist für geteilte lokale Verbindungen über Projektgrenzen hinweg ein festes Arbeitsverzeichnis nötig. Eine geteilte Verbindung hat keine Roots. Beginnen Sie deshalb mit einem schreibgeschützten Dienst, der den Umfang seiner Ressourcen klar festlegt. Hängt das Werkzeugverhalten vom aufrufenden Repository ab, messen Sie die Änderung, bevor Sie auf eine geteilte Verbindung umstellen. Dokumentation zu geteilten MCP-Verbindungen

Auch ein Skriptlauf braucht ein klares Ende

OpenCode 2.2.6 ergänzt --archived. Damit können Skript- oder CI-Sitzungen archiviert starten und aus normalen Sitzungslisten herausbleiben. Das betrifft die Darstellung der Sitzung. Halten Sie Ergebnis, Worktree-Pfad und Testausgaben dort fest, wo Prüfende sie finden. Verwenden Sie das Flag, sobald der Patch auch ohne Eintrag in der normalen Liste zuverlässig auffindbar ist. Laut den Versionshinweisen vom 6. November überspringt --continue archivierte Sitzungen. OpenCode v2.2.6

Dieselbe Version ändert das Ende eines Skriptlaufs. OpenCode wartet vor dem Beenden auf durch den Prompt gestartete Hintergrundbefehle, Unteragenten und Bildaufgaben. Laut Versionshinweisen hat diese Wartephase kein internes Zeitlimit. Ein Entwicklungsserver oder Dateiwächter kann den Lauf daher offen halten. Bevorzugen Sie für automatisierte Tests Befehle, die nach der Prüfung enden, und geben Sie dem umgebenden CI-Schritt ein Zeitlimit. Unterscheiden Sie abgebrochene Läufe, fehlgeschlagene Tests und Erfolgsmeldungen des Agenten. Bei einer Zeitüberschreitung prüfen Sie die tatsächlichen Änderungen vor einem Neustart oder einer Integration. OpenCode v2.2.6

Beurteilen Sie nach einem erfolgreichen Pilot mehr als die Fertigmeldung des Agenten. Wie lange dauert die Einrichtung? Wie lange braucht jemand, um die Änderung zu verstehen und zu überprüfen? Wie oft muss eine fachfremde Änderung korrigiert oder ein hängendes Werkzeug untersucht werden? Vergleichen Sie ähnlich große Aufgaben einschließlich Einrichtung und Prüfung. Ein eigener Worktree ist am wertvollsten, wenn der Patch klein genug bleibt, dass eine Person Verantwortung dafür übernehmen kann.

Ein sauberer Checkout macht Verantwortung sichtbar

Das Worktree-Flag gibt der prüfenden Person einen eindeutigen Ausgangspunkt. Sie kann den Anfangsstand sehen, die Änderung prüfen und den Test erneut ausführen, während die andere Person weiterarbeitet. Machen Sie Verbindungsfreigaben und Ausführungsrechte ebenso eindeutig. Eine gute Übergabe liefert einen kleinen Patch, an dem sich Ausgangspunkt, Änderung und Integrationsnachweis ablesen lassen.

Quellen

• Offizieller Terminal-Screenshot von OpenCode und Repository-Lizenz

• OpenCode v2.2.6 vom 6. November 2026

• OpenCode-CLI-Dokumentation

• OpenCode-V2-Berechtigungen

• Geteilte MCP-Verbindungen in OpenCode

• Git-Handbuch zu Worktrees

---

Wenn Sie die Entscheidungen und Experimente hinter Ihrer Arbeit durchsuchbar festhalten möchten, erstellen Sie ein Telli.sh-Konto.