OpenCode 2.0, was neu ist und wie ihr sicher umsteigt

Montagmorgen, Terminal auf, opencode gestartet. Und plötzlich fragt der Agent nach einem Upgrade auf eine neue Hauptversion. Genau so ging es vielen Teams Mitte Oktober. OpenCode 2.0 war schon seit Juli als Beta unterwegs. Dann hat Anomaly die Version offiziell vorgestellt und den Changelog auf die 2.x Serie umgestellt.

Bei uns ist OpenCode der einzige Coding Agent im Produktivbetrieb. Wir haben uns jede Änderung im eigenen Setup angeschaut. In diesem Artikel steht, was OpenCode 2.0 wirklich neu macht, welche Breaking Changes euch treffen und worauf ihr bei Permissions achten müsst, bevor das ganze Team umsteigt.

Was ist neu in OpenCode 2.0

Anomaly nennt die Version in der offiziellen Ankündigung einen großen Umbau. Gebaut wurde er aus den Erfahrungen von Millionen täglicher Nutzer. Die wichtigsten Neuerungen auf einen Blick:

• Ein Service für alles. Ein Hintergrundprozess, an dem Terminal, Weboberfläche und Desktop App hängen.
• Neue API. Komplett neu gebaut, dazu das Paket @opencode/client für eigene Skripte.
• Code Mode. MCP Server werden zu Funktionen, die der Agent in einem Skript aufruft.
• Background Tasks. Subagents und lange Shell Befehle laufen parallel zum Hauptagent.
• Plugins. Über 80 interne Plugins, TUI Plugins sind stabil, alles lädt per Hot Reload.
• SDK. Mit @opencode/sdk lässt sich OpenCode in eigene Anwendungen einbetten.

Eine gute Zusammenfassung der Architektur liefert auch The New Stack. Dort steht ebenfalls, warum der lange Weg von der Beta zur Hauptversion für Verwirrung gesorgt hat. Viele wussten schlicht nicht, ob 2.0 schon stabil ist.

Ein OpenCode Service für Terminal, Desktop und Web

Den Client Server Aufbau hatte OpenCode von Anfang an. Genutzt haben ihn aber fast nur Power User. In Version 2.0 startet der Server automatisch als ein einziger Prozess im Hintergrund. Terminal, Browser und Desktop App sprechen alle mit diesem Prozess.

Im Alltag heißt das: Ihr startet eine Session im Terminal und arbeitet am Laptop in der Desktop App weiter. Eigene Skripte finden den lokalen Service von selbst. Das ist praktisch für Aufgaben, die nachts oder im Takt laufen sollen.

import { OpenCode } from "@opencode/client"
import { Service } from "@opencode/client/service"

const endpoint = await Service.ensure()
const client = OpenCode.make({
  baseUrl: endpoint.url,
  headers: Service.headers(endpoint),
})

const session = await client.session.create({
  location: { directory: process.cwd() },
})

await client.session.prompt({
  sessionID: session.id,
  text: "Review the current changes",
})

Das Beispiel stammt aus der Ankündigung. Mit opencode pair verbindet ihr außerdem weitere Geräte. Der Befehl gibt einen Link aus, der einmal funktioniert und nach fünf Minuten abläuft.

Spannend ist, dass OpenCode seine eigene API kennt. Der Agent legt für neue Arbeit selbst einen Git Worktree an, verschiebt die Session dorthin, findet hängende Sessions und stoppt sie. Für uns passt das genau zu der Regel, die wir in jedem Projekt setzen: Der Agent arbeitet nie direkt auf dem Hauptbranch.

Code Mode in OpenCode 2.0 einfach erklärt

Bisher rief ein Agent jedes Tool einzeln auf. Ergebnis holen, nachdenken, nächstes Tool. Jede Runde kostet Zeit und Kontext. Code Mode dreht das um. Das Paket @opencode/codemode wandelt MCP Server und OpenAPI Endpunkte in Funktionen um. Der Agent schreibt ein kleines JavaScript Skript, das mehrere Tools in einem Durchlauf aufruft.

Ein Beispiel aus der Ankündigung: Der Agent holt offene Bugs aus GitHub, geht die Liste durch und legt für jeden Bug ein Ticket in Linear an. Ein Skript, ein Durchlauf, keine zehn Einzelschritte.

In Version 2.0 laufen alle MCP Server automatisch im Code Mode. Laut Anomaly bleibt der Kontext damit schlank, auch wenn sehr viele Server eingebunden sind. Wichtig bleibt trotzdem das Modell. Nicht jedes Modell schreibt gute Skripte für Tool Aufrufe. Welche Modelle das gut können, zeigt unser Vergleich der KI Modelle für MCP und Tool Handling.

Background Tasks und Subagents in OpenCode

Moderne Modelle sind stark darin, Arbeit zu verteilen. OpenCode 2.0 lässt sie das jetzt auch tun. Zwei Dinge laufen ab sofort im Hintergrund:

• Subagents. Der Hauptagent gibt eine Aufgabe ab und arbeitet weiter. Ihr könnt das auch selbst auslösen, sogar mit einem anderen Modell. Ein Subagent macht etwa das Code Review, während ihr weiter promptet.
• Shell Befehle. Testläufe und Builds blockieren den Agenten nicht mehr. Er bekommt Bescheid, sobald sie fertig sind.

Läuft etwas länger als gedacht, schiebt ihr es mit ctrl+b in den Hintergrund. Für Quality Gates ist das ein echter Gewinn. PHPUnit, PHPStan oder ein Cypress Lauf laufen, die Arbeit stoppt nicht. Auch delegierte Commands laufen jetzt automatisch im Hintergrund und melden ihr Ergebnis an die Session zurück. Wie ihr eigene Commands baut, steht in OpenCode Commands erstellen.

OpenCode Plugins und SDK in Version 2

Version 1 hatte ein Plugin System, das laut Anomaly nie die nötige Aufmerksamkeit bekam. Das Team hat deshalb fast jedes Feature von 2.0 selbst als internes Plugin gebaut. Über 80 sind es inzwischen. So bleibt die Plugin API gepflegt, weil das Team sie jeden Tag selbst nutzt.

TUI Plugins sind jetzt stabil. Alles in 2.0 lädt per Hot Reload. OpenCode kann sich also mitten in der Session ein Plugin schreiben und sofort nutzen. Das ist mächtig, für Teams aber auch ein Punkt für die Guardrails. Ein Agent, der sich selbst erweitert, braucht klare Regeln.

Neu ist das SDK @opencode/sdk. Es ist derselbe Code, der die CLI antreibt. Damit baut ihr eure eigene OpenCode Variante, etwa für einen Server. Anomaly sagt selbst, dass das SDK noch in Entwicklung ist. Für produktive Integrationen würden wir es heute noch nicht einsetzen.

OpenCode 2.0 installieren

Auf macOS und Linux nutzt ihr das offizielle Skript. Wichtig: Version 1 und Version 2 heißen beide opencode und laufen standardmäßig nicht mehr nebeneinander. Habt ihr Version 1 über einen Paketmanager installiert, entfernt ihr sie vorher.

curl -fsSL https://opencode.ai/v2/install | bash

opencode --version
cd /euer/projekt
opencode

Laut Doku gibt es Version 2 auch über Homebrew, npm, bun, pnpm, yarn, AUR und mise. Bei mise braucht ihr mindestens Version 2026.10.9, ältere Versionen installieren noch OpenCode 1. Unter Windows werden Paketmanager nicht unterstützt. Dort nehmt ihr das Binary oder WSL2. Für Container gibt es Images mit festen Versionen, etwa ghcr.io/anomalyco/opencode:2.0.0.

Von OpenCode 1 auf OpenCode 2 upgraden

Wer schon mit Version 1 arbeitet, macht das Upgrade in zwei Schritten. Erst auf die neueste 1.x Version, dann der Sprung auf die Hauptversion.

# Upgrade auf OpenCode 2.0
opencode upgrade --major

# Alternativ in der laufenden TUI
/update

Ein Detail ist leicht zu übersehen. Seit den Release Notes vom 11. Oktober installieren sich Updates nicht mehr automatisch. Ihr müsst das Upgrade also selbst anstoßen. Für Teams ist das gut, weil niemand unbemerkt auf eine neue Version rutscht.

Der offizielle Migrationsguide nennt drei Breaking Changes:

1. Plugins aus Version 1 laufen nicht mehr. Datei verschieben reicht nicht, ihr müsst sie auf die neue Plugin API portieren.
2. Die Server API ist komplett neu. Alle Integrationen, die die alte API aufrufen, müssen auf @opencode/client umziehen.
3. Die TUI Einstellungen ziehen um. Aus mehreren tui.json Dateien wird eine globale ~/.config/opencode/cli.json. Das migriert OpenCode beim ersten Start automatisch.

Alles andere soll weiterlaufen. Eure opencode.json, Agents, Commands und Skills unter .opencode/ bleiben gültig. Der Guide empfiehlt eine Reihenfolge: Erst Version 2 mit der alten Config starten, dann Modelle, Zugänge, Agents, Permissions und MCP Server prüfen. Danach Plugins und Integrationen portieren. Das neue Config Format ist optional.

OpenCode Config von Version 1 auf 2 umstellen

OpenCode 2.0 liest das alte Format weiter ein. Wer umstellen will, kann OpenCode die Arbeit selbst machen lassen. Der Guide gibt dafür einen fertigen Prompt vor. Diese Felder ändern sich am häufigsten:

Bereich	OpenCode 1	OpenCode 2
Permissions	permission pro Tool	permissions als geordnete Liste
Shell Rechte	bash	shell
Subagents	task und subtask	subagent
Agents	agent mit prompt	agents mit system
Model Variante	eigenes Feld variant	provider/modell#variante
MCP Server	direkt unter mcp, Feld enabled	unter mcp.servers, Feld disabled
Provider	provider mit npm	providers mit package
Snapshots	snapshot	snapshots
Plugins	plugin	plugins

So sieht ein MCP Server im neuen Format aus. Der Timeout teilt sich jetzt in Katalog und Ausführung:

{
  "mcp": {
    "servers": {
      "github": {
        "type": "local",
        "command": ["github-mcp-server", "stdio"],
        "disabled": false,
        "timeout": {
          "catalog": 30000,
          "execution": 30000
        }
      }
    }
  }
}

OpenCode 2 Permissions richtig setzen

Das ist der Teil, den wir jedem Team zuerst zeigen. Version 1 fragt nach, bevor der Agent auf Pfade außerhalb des Projekts zugreift. Version 2 tut das nicht mehr. Die Aktion external_directory ist standardmäßig erlaubt.

Für ein Team mit Zugriff auf mehrere Repositories, SSH Keys oder lokale Kundendaten ist das ein Risiko. Holt das alte Verhalten mit einer eigenen Regel zurück. Gleichzeitig lohnt der Blick auf die neue Struktur. Permissions sind jetzt eine geordnete Liste mit Aktion, Ressource und Effekt:

{
  "permissions": [
    { "action": "external_directory", "resource": "*", "effect": "ask" },
    { "action": "shell", "resource": "git push *", "effect": "ask" },
    { "action": "edit", "resource": "*", "effect": "allow" },
    { "action": "websearch", "resource": "*", "effect": "deny" }
  ]
}

Die Details zur Reihenfolge der Regeln stehen in der Permissions Doku. Wer Regeln für das ganze Team erzwingen will, nutzt policies statt normaler Settings. Nur Policies lassen sich von Nutzern nicht einfach überschreiben. Wie wir Permissions grundsätzlich denken, haben wir in OpenCode Permissions richtig einstellen beschrieben. Die Ideen gelten weiter, nur die Syntax ist neu.

Noch ein Punkt für Teams, die aus Claude Code kommen. Version 2 liest nur noch AGENTS.md. Der Fallback auf CLAUDE.md fehlt. Verschiebt eure Projektregeln, sonst arbeitet der Agent ohne sie.

OpenCode 2 ohne LSP, warum Quality Gates wichtiger werden

Eine Änderung fällt in den Ankündigungen kaum auf. OpenCode 2.0 akzeptiert die lsp Konfiguration noch, startet aber keine Language Server mehr. Es gibt keine LSP Tools und keine LSP Diagnosen. Die Doku empfiehlt, stattdessen die Lint, Typecheck und Compiler Befehle des Projekts zu nutzen.

Für uns ändert das wenig, weil wir genau so arbeiten. Der Agent prüft jede Änderung gegen echte Quality Gates. In PHP Projekten sind das PHPStan, Psalm und PHPUnit, im Frontend tsc, ESLint und Cypress. Diese Befehle gehören in die AGENTS.md, damit der Agent sie nach jeder Änderung startet. Mit den neuen Background Tasks laufen sie nebenher.

Wer sich bisher auf LSP Diagnosen verlassen hat, sollte das vor dem Umstieg klären. Ohne Tests und statische Analyse merkt sonst niemand, wenn der Agent einen falschen Typ erfindet. Warum das Werkzeug um das Modell herum so viel ausmacht, steht in Agent Harness, warum der Coding Agent mehr ausmacht als das KI Modell.

Lohnt sich das Upgrade auf OpenCode 2.0

Für neue Setups ist die Antwort einfach. Startet direkt mit Version 2. Die Dokumentation ist auf 2.x umgestellt, neue Features kommen nur noch dort.

Für bestehende Teams empfehlen wir einen geordneten Umstieg:

1. Eine Person testet Version 2 auf einem eigenen Branch mit der bestehenden Config.
2. Permissions prüfen, vor allem external_directory.
3. Projektregeln aus CLAUDE.md in AGENTS.md verschieben.
4. Lint, Typecheck und Tests als feste Befehle für den Agenten hinterlegen.
5. Eigene Plugins und Integrationen mit der alten Server API auflisten und portieren.
6. Erst dann das ganze Team umstellen und die Version pinnen.

Wer OpenCode in Pipelines nutzt, prüft auch die OpenCode GitHub Action und alle Skripte, die den Server ansprechen. Im Server Modus setzt ihr das Passwort jetzt über OPENCODE_PASSWORD, der Benutzername ist fest opencode. Wer noch bei Version 1 bleibt, braucht mindestens v1.18.22. Diese Version schließt eine Remote Code Execution Lücke im Server Modus.

Alle Details zu Modellen, Installation und unserer Einordnung findet ihr auf unserer Übersichtsseite zu OpenCode als Open Source Coding Agent. Welche lokalen Modelle gut mit OpenCode laufen, zeigt die Übersicht der Ollama Modelle für Vibe Coding.

Fazit

OpenCode 2.0 ist mehr als ein Versionssprung. Ein gemeinsamer Service, eine saubere API, Code Mode und Background Tasks machen den Agenten zur Plattform für das ganze Team. Gleichzeitig ändern sich Dinge, die schnell untergehen. Pfade außerhalb des Projekts sind standardmäßig offen, LSP fällt weg und nur noch AGENTS.md zählt. Wer diese drei Punkte vor dem Umstieg klärt, bekommt mit Version 2 den besten OpenCode, den es bisher gab.