OpenCode 2.2.6, was das Update für Skripte und CI Pipelines bringt

Nachts läuft ein Review Job. Er startet opencode run, der Agent prüft die offenen Änderungen und die Pipeline wird grün. Am Morgen ist die Inbox voll mit Sessions, die niemand angelegt hat. Und der Testlauf, den der Agent angestoßen hat, war noch gar nicht fertig, als der Job schon vorbei war. Genau hier setzt OpenCode 2.2.6 an.

Das Update ist kein großer Versionssprung wie OpenCode 2.0. Für alle, die den Agent in Skripten, Pipelines oder geplanten Läufen nutzen, ist es trotzdem eines der wichtigsten Updates der 2.x Serie. Bei uns ist OpenCode der einzige Coding Agent im Produktivbetrieb. Hier steht, was neu ist und was ihr vor dem Einsatz in der CI klären solltet.

Was ist neu in OpenCode 2.2.6

Der offizielle Changelog listet fünf Highlights, 14 Verbesserungen und 33 Fixes. Für Teams zählen vor allem diese Punkte:

• Worktree pro Lauf. opencode run -w startet die Session in einem neuen Git Worktree.
• Archivierte Läufe. --archived hält Skript und CI Sessions aus Inbox und Session Liste heraus.
• Warten auf Hintergrundjobs. opencode run endet erst, wenn gestartete Shell Befehle, Subagents und Bildjobs fertig sind.
• Geteilte MCP Verbindungen. Mit pool: true nutzen Projekte mit gleichem Setup eine gemeinsame Verbindung.
• Mehr Sicherheit. Schärfere Regeln für die Server API, Webfetch und Code Mode.
• Mobile und Desktop. Ein Touch Dock für den Composer auf Tablet und Handy, dazu neue Slots und Themes für GUI Plugins.

OpenCode run im eigenen Git Worktree starten

In jedem Projekt setzen wir eine feste Regel. Der Agent arbeitet nie direkt auf dem Hauptbranch. In der TUI und der Desktop App war das mit Worktrees schon gut lösbar. Bei opencode run musstet ihr den Worktree bisher selbst anlegen und wieder aufräumen. Jetzt reicht ein Flag:

# Neue Session in einem frischen Git Worktree
opencode run -w "Prüfe die offenen Änderungen gegen PHPStan und PHPUnit"

# Worktree mit eigenem Namen
opencode run --worktree=review-nightly "Fasse die Testergebnisse zusammen"

Mit einem Namen findet ihr den Worktree später leichter wieder. Das hilft, wenn mehrere geplante Läufe parallel im selben Repository arbeiten. Jeder Lauf hat seinen eigenen Stand und keiner überschreibt die Dateien eines anderen.

OpenCode Sessions automatisch archivieren

Jeder Aufruf von opencode run erzeugt eine Session. Bei einem Review pro Pull Request kommen schnell Dutzende am Tag zusammen. Mit --archived legt OpenCode die Session direkt im Archiv ab. Sie taucht weder in der Inbox noch auf dem Home Screen noch in der Session Liste der TUI auf. Auch --continue überspringt archivierte Sessions, damit ihr nicht aus Versehen an einem CI Lauf weiterarbeitet.

# Worktree und Archiv kombiniert
opencode run -w --archived "Prüfe die Änderungen gegen die Quality Gates"

Warum opencode run jetzt auf Hintergrundjobs wartet

Seit OpenCode 2.0 laufen Subagents und lange Shell Befehle im Hintergrund. In der TUI ist das ein Gewinn. In Skripten war es eine Falle. Der Agent startete den Testlauf, der Prompt war fertig und opencode run beendete sich, bevor das Ergebnis da war.

Ab 2.2.6 wartet opencode run auf alle Jobs, die der Prompt gestartet hat. Danach darf das Modell noch auf die Ergebnisse reagieren. Während es wartet, zeigt die Ausgabe an, wie viele Jobs noch laufen. Mit --format json kommt dafür ein eigenes Event. Für Quality Gates ist das genau richtig. PHPUnit, PHPStan oder ein Cypress Lauf landen jetzt wirklich in der Antwort des Agenten.

Der Haken: Es gibt kein Zeitlimit. Startet der Agent einen Dev Server oder einen File Watcher, bleibt der Lauf offen, bis ihr ihn mit Ctrl+C oder SIGTERM beendet. In einer Pipeline heißt das im schlimmsten Fall, dass der Job hängt, bis der Runner ihn abschießt. Setzt deshalb immer einen Timeout:

jobs:
  opencode-review:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://opencode.ai/v2/install | bash
      - run: opencode run -w --archived "Prüfe die Änderungen gegen die Quality Gates"

In GitLab CI erfüllt das Keyword timeout am Job denselben Zweck. Auch der Abbruch ist jetzt sauber geregelt. SIGTERM beendet die Session samt Hintergrundjobs und gibt den Exit Code 143 zurück. Eure Pipeline erkennt also eindeutig, dass der Lauf abgebrochen wurde.

Ein Hinweis für alle, die noch mit der alten GitHub Action arbeiten. Anomaly veröffentlicht sie seit v2.2.0 nicht mehr. Ihr ruft opencode run stattdessen selbst im Workflow auf, wie im Beispiel oben. Wie wir Pipelines für KI Code grundsätzlich aufbauen, steht auf unserer Seite zu Vibe Coding CI/CD Pipelines.

MCP Verbindungen in OpenCode teilen

Wer viele Projekte offen hat, kennt das Problem. Jedes Projekt startet seine eigenen MCP Server, auch wenn das Setup identisch ist. Mit pool: true schaltet ihr für einen MCP Server das Pooling ein. Projekte mit gleichem Setup teilen sich dann eine Verbindung. Das spart Prozesse, und OpenCode startet schneller.

Dazu kommt eine kleine, aber spürbare Änderung. Vor einem Modellaufruf wartet OpenCode bis zu zwei Sekunden auf MCP Server, die sich gerade noch verbinden. So sind deren Tools schon im ersten Prompt und bei opencode run verfügbar. Welche Modelle mit vielen Tools gut umgehen, zeigt unser Vergleich der KI Modelle für MCP und Tool Handling.

Mehr Sicherheit für Server API, Webfetch und Code Mode

Ein Teil der Fixes betrifft direkt die Sicherheit. Die Server API liefert Dateien und Medien aus dem Projekt nur noch als abgeschottete Downloads aus. Anfragen von fremden Origins an /api/* werden abgelehnt. Eine Datei im Projekt kann damit keine Skripte auf dem Origin des Servers ausführen.

• Webfetch und Code Mode lehnen URLs mit Zugangsdaten ab und ignorieren das Fragment nach dem Rautezeichen beim Abgleich mit euren Regeln.
• Code Mode prüft jeden Redirect gegen eure Webfetch Regeln.
• Session Move fragt nach der Permission external_directory, bevor eine Session das Projekt verlässt.
• Die Policy Aktion websearch.use steuert die Websuche des Agenten zentral für das ganze Team.

Gerade der letzte Punkt ist für Teams spannend. Wer Regeln verbindlich machen will, setzt sie als Policy, weil Nutzer sie dort nicht einfach überschreiben. Die Grundlagen stehen in der Permissions Doku. Wie wir Permissions grundsätzlich denken, haben wir in OpenCode Permissions richtig einstellen beschrieben.

Neu und noch experimentell ist eine Bytecode VM für Code Mode. Sie ist standardmäßig aus und lässt sich mit experimental.codemode_vm: true oder OPENCODE_FLAGS=codemode_vm einschalten. In Team Setups würden wir solche Flags erst nach einem eigenen Test aktivieren.

OpenCode 2.2.6 Neuerungen im Überblick

Neuerung	Befehl oder Einstellung	Nutzen im Team
Worktree pro Lauf	opencode run -w	Der Agent arbeitet nie direkt auf dem Hauptbranch
Archivierte Läufe	opencode run --archived	CI Sessions landen nicht in der Inbox
Warten auf Hintergrundjobs	Standard bei opencode run	Testergebnisse fließen in die Antwort ein
Sauberer Abbruch	SIGTERM, Exit Code 143	Pipelines erkennen Abbrüche zuverlässig
Geteilte MCP Verbindungen	pool: true	Weniger Prozesse, schnellerer Start
Websuche steuern	websearch.use	Eine Regel für das ganze Team
Scroll Position halten	session.submit_scroll: "keep"	Lesestelle bleibt nach dem Senden
Code Mode VM	experimental.codemode_vm: true	Experimentell, erst testen

OpenCode auf 2.2.6 aktualisieren

Updates installieren sich nicht mehr automatisch. Ihr stoßt sie selbst an, im Terminal oder direkt in der laufenden TUI. Danach prüft ihr die Version.

# Update im Terminal
opencode upgrade

# Alternativ in der laufenden TUI
/update

# Version prüfen
opencode --version

Wer noch auf Version 1 arbeitet, geht den Weg über opencode upgrade --major. Was dabei bricht, steht im Artikel zu OpenCode 2.0. In Pipelines pinnt ihr die Version am besten fest, damit ein neues Release nicht unbemerkt mitten in die Woche rutscht. Alle Änderungen im Detail findet ihr im Release auf GitHub.

Unsere Einordnung

OpenCode 2.2.6 macht opencode run zu einem Werkzeug, das in einer Pipeline wirklich trägt. Eigener Worktree, eigenes Archiv und ein Lauf, der auf seine Tests wartet. Das passt genau zu unserer Arbeitsweise. Der Agent schreibt Code, die Quality Gates entscheiden, ob er gut genug ist.

Der fehlende Timeout ist der Punkt, den ihr vor dem Update klären solltet. Ohne ihn kann ein einziger Dev Server eure Runner blockieren. Warum das Werkzeug um das Modell herum so viel ausmacht, steht in Agent Harness, warum der Coding Agent mehr ausmacht als das KI Modell. Alle Details zu Modellen, Installation und Einordnung findet ihr auf unserer Übersichtsseite zu OpenCode als Open Source Coding Agent.