OpenCode: der Open-Source-Code-Agent, installiert und zerlegt

Ein Open-Source-Code-Agent verspricht, dich nicht an einen einzigen Anbieter zu binden. Das Modell wählt man selbst, der Code bleibt auf der eigenen Maschine, die Lizenz ist freizügig. Ich habe OpenCode installiert, ohne das System anzufassen oder auch nur einen Zugangsdatensatz einzugeben, bevor ich entdeckte, dass ein vergessener Variablen-Export genügt, um es dazu zu bringen, die bereits für andere Tools installierten Skills zu laden.

OpenCode, drei Oberflächen unter MIT-Lizenz

OpenCode wird von Anomaly entwickelt und unter MIT-Lizenz im Repository anomalyco/opencode veröffentlicht, das am 7. September 2026 rund 206.000 Sterne zeigte. Das Tool bezeichnet sich selbst als „an open source agent that helps you write code in your terminal, IDE, or desktop“. Es liegt in drei Oberflächen vor: ein Terminal-Client (TUI), eine Editor-Erweiterung und eine Desktop-Anwendung in Beta für macOS, Windows und Linux.

Ein LSP lädt im Prinzip automatisch je nach erkannter Sprache, und mehr als 75 Modellanbieter werden über Models.dev und das AI SDK unterstützt, von der kostenpflichtigen API bis zum lokalen Modell. In meinem Test-Miniprojekt vermerkte das Protokoll jedoch „all LSPs are disabled“: Die Spracherkennung genügt nicht, der passende Server muss vorhanden sein, damit sich die Funktion aktiviert. Die Website behauptet außerdem „OpenCode does not store any of your code or context data“. Standardmäßig geht nichts an die Server von Anomaly, aber alles bleibt in einer lokalen SQLite-Datenbank, wie der nächste Abschnitt zeigt.

OpenCode reiht sich in eine bereits lange Liste von Kommandozeilen-Agenten ein: Unser Überblick über Code-Agenten vergleicht sie alle. Dieser Artikel konzentriert sich darauf, was man entdeckt, wenn man diesen hier installiert und Stück für Stück zerlegt.

OpenCode installieren, ohne etwas auf dem System zu hinterlassen

Das npm-Paket opencode-ai installiert eine kompilierte Binärdatei (opencode-darwin-arm64 auf diesem Mac) hinter einer ausführbaren Datei opencode.exe. Um nichts an globalen Orten zu hinterlassen, geht es zu einem temporären Labor-Präfix, mit einem lokalen npm-Cache und einem HOME isoliert für alle folgenden Befehle:

mkdir -p docker/articles/2026-09-07/lab/opencode-agent-code-open-source/{prefix,home,projet-demo}
cd docker/articles/2026-09-07/lab/opencode-agent-code-open-source

npm install opencode-ai --prefix ./prefix --cache ./prefix/.npm-cache

export HOME="$PWD/home"
./prefix/node_modules/.bin/opencode --version

Der Befehl liefert 1.18.29, veröffentlicht laut den GitHub-Releases am 4. September 2026 um 23:47 Uhr, drei Tage vor diesem Test. Fünfte Version in acht Tagen: 1.18.25 bis 1.18.29 zwischen dem 28. August und dem 4. September. Die npm-Registry bestätigt, dass es sich um die neueste verfügbare Version handelt. Die Dokumentation bietet außerdem ein Skript curl -fsSL https://opencode.ai/install | bash sowie Homebrew-, Scoop- oder pacman-Pakete an, ich bin bei npm geblieben, damit die gesamte Installation in einem Ordner Platz findet, den man am Ende löscht.

Die Installation hört hier nicht unbedingt auf. Sobald einige Befehle aus dem Projekt heraus ausgeführt wurden, hat OpenCode von sich aus 54 MB an Abhängigkeiten in .opencode/node_modules installiert, ohne zu fragen: sein eigenes Plugin-SDK, die Bibliothek effect, und eine überraschendere Anwesenheit, kubernetes-types. Eine .opencode/.gitignore stand bereits bereit, um sie von der Git-Nachverfolgung auszuschließen.

Wo OpenCode seine Konfiguration liest

Sobald HOME isoliert ist, zeigt der Befehl opencode debug paths, ein Diagnose-Unterwerkzeug, das im Hauptmenü fehlt, die XDG-artige Struktur, die sich OpenCode in diesem falschen persönlichen Verzeichnis aufgebaut hat (Pfade zur besseren Lesbarkeit gekürzt):

opencode debug paths

home    .../lab/opencode-agent-code-open-source/home
config  .../home/.config/opencode
data    .../home/.local/share/opencode
cache   .../home/.cache/opencode
state   .../home/.local/state/opencode
tmp     /var/folders/.../T/opencode

Die Datei opencode.log, geschrieben in data/log, dokumentiert die genaue Lesereihenfolge beim Start: zuerst der globale Konfigurationsordner (opencode.json, .jsonc), dann, ausgehend vom aktuellen Ordner, opencode.json und .opencode/opencode.json des Projekts. Der in die Binärdatei eingebaute Skill, lesbar mit opencode debug skill, dokumentiert dieselbe Hierarchie, mit einer Tabelle, die es wert ist, übernommen zu werden:

Die Konfigurationen jedes Geltungsbereichs werden zusammengeführt (Deep-Merge), wobei das Projekt über die globale Ebene siegt. Die letzte Tabellenzeile reicht am weitesten. OpenCode liest ohne zusätzliche Erklärung die bereits für Claude Code und für andere mit dem offenen Standard Agent Skills kompatible Agenten installierten Skills liest, beschrieben in unserem Leitfaden zum SKILL.md.

Die Skills: Wie weit geht die automatische Erkennung?

Um zu prüfen, was die eingebaute Dokumentation sagt, habe ich zwei Köder-Skills direkt in das falsche HOME eingefügt, genau dort, wo OpenCode sie sucht, bevor ich dieselbe Diagnose erneut ausgeführt habe:

mkdir -p home/.claude/skills/decoy-claude home/.agents/skills/decoy-agents
# ein minimales SKILL.md (Frontmatter name + description) in jedem Ordner
opencode debug skill

Ergebnis: vier erkannte Skills, der eingebaute Skill, der Projekt-Skill, und die beiden Köder, jeder mit seinem vollständigen Pfad in home/.claude/skills/… und home/.agents/skills/…. OpenCode respektiert schlicht die Variable HOME, die man ihm gibt, es schaut nur weiter als in seinen eigenen Konfigurationsordner.

Ohne erneuten Export von HOME im Befehl fällt dieselbe Auflistung auf das echte persönliche Verzeichnis der Maschine zurück und fördert 120 Skills zutage, die tatsächlich für Claude Code und andere Agenten installierten. Kein Ausbrechen aus einer Sandbox darin. Ein einziger Befehl ohne ausdrückliches HOME genügt, um einen vermeintlich isolierten Test wieder an dein echtes persönliches Verzeichnis zu kleben, und damit an die bereits für andere Tools installierten, im Projekt nie deklarierten Skills. Der Befehl selbst ist aufschlussreich: Es gibt kein opencode skill list auf der ersten Ebene, man muss über opencode debug skill gehen, ein Diagnosewerkzeug.

MCP: einen lokalen Server konfigurieren und abfragen

Die Konfigurationsdatei des Projekts deklariert einen lokalen MCP-Server, die zugehörigen Berechtigungen, und beschränkt den Zugriff auf das Werkzeug für den Agenten plan:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "slug": {
      "type": "local",
      "command": ["node", "./mcp/serveur.mjs"],
      "enabled": true
    }
  },
  "permission": {
    "edit": { "*": "ask", "docs/**": "allow" },
    "bash": { "*": "ask", "git status": "allow", "git diff *": "allow", "rm *": "deny" },
    "webfetch": "deny",
    "skill": { "*": "allow" }
  },
  "agent": {
    "plan": { "tools": { "slug_*": false } }
  }
}

Der Server, mcp/serveur.mjs, ist ein eigenständiges Node-Skript von rund vierzig Zeilen, das JSON-RPC 2.0 über die Standardeingabe spricht und ein einziges Werkzeug freigibt, slug_fr:

const TOOLS = [{
  name: "slug_fr",
  description: "Transforme un titre francais en slug d'URL (minuscules, sans accent).",
  inputSchema: {
    type: "object",
    properties: { titre: { type: "string", description: "Le titre a convertir" } },
    required: ["titre"]
  }
}];

function slug(titre) {
  return titre.normalize("NFD").replace(/[\u0300-\u036f]/g, "")
    .toLowerCase().replace(/[^a-z0-9]+/g, "-").replace(/^-+|-+$/g, "");
}

opencode mcp list bestätigt die Verbindung:

opencode mcp list

MCP Servers
  slug   connected
    node ./mcp/serveur.mjs

1 server(s)

Ein Projekt-Skill, slug-gekkode, erklärt die Geschäftsregel (maximal fünf Wörter, ohne Artikel) und verweist auf das Werkzeug. Ein Hin und Her mit opencode run löst beide nacheinander aus (Ausgabe von Farbcodes und Icons bereinigt, Inhalt unverändert):

opencode run "Utilise la regle de slug du projet pour convertir ce titre : Les secrets d'une bonne architecture PHP"

> build - big-pickle
Skill "slug-gekkode"
slug_slug_fr {"titre":"Les secrets d'une bonne architecture PHP"}

Le slug genere par l'outil MCP est : les-secrets-d-une-bonne-architecture-php

Mais selon les regles du skill (max 5 mots, sans article ni preposition),
le slug correct est : secrets-bonne-architecture-php

Der angezeigte Werkzeugname, slug_slug_fr, zeigt die Namenskonvention. OpenCode stellt jedem MCP-Werkzeug den Namen des in der Config deklarierten Servers voran (slug), gefolgt vom Namen des freigegebenen Werkzeugs (slug_fr), daher die Wiederholung. Das Modell hat den Skill anhand seiner Beschreibung gewählt, das Werkzeug aufgerufen, dann das Ergebnis von Hand neu berechnet, um die Fünf-Wörter-Regel einzuhalten. Ein Skill, der ein Werkzeug ergänzt, statt es zu ersetzen, verhält sich genau so. Für einen entfernten Server beschreibt die Dokumentation einen Block "type": "remote" mit url und headers oder oauth, plus opencode mcp auth für den OAuth-Fluss. Das Thema wird in unserem Artikel über die Erstellung eines MCP-Servers in PHP vertieft.

Agenten und Berechtigungen, Regel für Regel

opencode agent list zeigt acht Agenten in diesem Projekt: build (Standard-Hauptagent, weitreichender Zugriff), plan (Hauptagent, Lesen und Planung), compaction, summary und title (intern), explore und general (Subagenten), und relecteur, deklariert in .opencode/agents/relecteur.md:

---
description: Relit un article et signale les fautes, sans jamais modifier de fichier.
mode: subagent
temperature: 0.1
permission:
  edit: deny
  bash: deny
---
Vous relisez un article de blog en francais. Vous signalez les erreurs, vous ne corrigez rien.

Jede Berechtigung akzeptiert allow, ask oder deny, nach Glob-Muster, wobei die spezifischste Regel gewinnt. Die Einstellung gilt für edit, bash, webfetch, skill, und sogar für ein bestimmtes MCP-Werkzeug wie slug_*. Der Agent plan des Projekts veranschaulicht das Prinzip: Seine Konfiguration deaktiviert das Werkzeug slug_* und erlaubt Schreiben nur in .opencode/plans/*.md, niemals im Code. Im nicht interaktiven Modus, ohne Terminal, um eine Frage zu beantworten, bleibt eine ask-Berechtigung nicht in der Warteschleife: Sie wird automatisch abgelehnt:

opencode run "Execute la commande shell : echo test-permission"

> build - big-pickle
! permission requested: bash (echo test-permission); auto-rejecting
Error: The user rejected permission to use this specific tool call.

$ echo $?
0

Das Standardverhalten ist also geschlossen: Ohne menschliche Aufsicht schlägt OpenCode lieber fehl, als einen nicht ausdrücklich erlaubten Befehl auszuführen. Der Exit-Code bleibt dennoch trotz des Fehlschlags bei 0, eine Falle für alle, die darauf eine Prüfung skripten. Das Thema Berechtigungen und Sandbox, allen diesen Agenten gemeinsam, wird in unserem Artikel über Code-Agenten, Sandbox und Berechtigungen vertieft.

Die Modelle: ein kostenloser Test, und der Fall der lokalen Modelle

Ohne Konto oder Schlüssel funktioniert opencode run "dis bonjour" schon beim ersten Befehl. Das standardmäßig verwendete Modell, big-pickle („stealth model“ laut seinem Datenblatt), gehört zu den sechs kostenlosen Modellen von OpenCode Zen, dem hauseigenen Gateway. Die fünf anderen sind MiMo-V2.5 Free, Ling 3.0 Flash Fin Free, zwei Varianten von Nemotron 3 und Muse Spark 1.3 Contributor Free. Die lokale SQLite-Datenbank (Tabelle message) hält den Austausch fest. Die Tabellen credential und account bleiben bei null Zeilen: kein Zugangsdatensatz für dieses Modell verlangt oder gespeichert, und Kosten von null im Sitzungsprotokoll.

Ein Markenmodell aus demselben Katalog (GPT, Claude, Gemini, Grok, DeepSeek, Qwen…) verlangt ein Konto bei OpenCode Zen und ein Zahlungsmittel. Abgerechnet wird pro Token, von 0,20 $ bis mehreren Dollar pro Million je nach Modell. Das Guthaben lädt sich automatisch um 20 $ auf, sobald es unter 5 $ fällt.

Für ein lokales Modell ist die Prüfung einfach:

which ollama
# Ollama nicht gefunden

Der von OpenCode zwischengespeicherte Modellkatalog bietet nur einen Cloud-Anbieter, ollama-cloud (Schlüssel OLLAMA_API_KEY), keinen eigenen Eintrag für ein lokales Ollama. Für einen lokalen Server, Ollama, llama.cpp oder LM Studio, beschreibt die Dokumentation einen generischen OpenAI-kompatiblen Anbieter, den man selbst deklarieren muss:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama-local": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://127.0.0.1:11434/v1" },
      "models": { "mon-modele": { "name": "Mon modele local" } }
    }
  }
}

Port 11434 und die native API (/api/generate, unter anderem) sind auf docs.ollama.com dokumentiert. Die von @ai-sdk/openai-compatible geforderte OpenAI-Kompatibilität klärt sich in zwei Aufrufen, geprüft an einem Ollama 0.34.0 im Container:

curl -s http://127.0.0.1:11434/v1/models
# {"object":"list","data":[{"id":"qwen2.5:0.5b","object":"model",
#   "created":1789038968,"owned_by":"library"}]}

curl -s http://127.0.0.1:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen2.5:0.5b","messages":[{"role":"user",
       "content":"Réponds par le seul mot OK."}],"max_tokens":5}'
# {"id":"chatcmpl-704","object":"chat.completion","model":"qwen2.5:0.5b",
#  "choices":[{"index":0,"message":{"role":"assistant","content":"OK."},
#   "finish_reason":"stop"}],
#  "usage":{"prompt_tokens":38,"completion_tokens":3,"total_tokens":41}}

Die Form ist genau die, die das SDK erwartet: object: "list" beim Katalog, ein vollständiges chat.completion-Objekt mit choices, finish_reason und usage bei der Completion. Ein unbekanntes Modell antwortet 404 mit dem OpenAI-Fehlerobjekt, und der Header Authorization wird mit beliebigem Wert akzeptiert: Das Feld apiKey des Anbieters darf irgendetwas enthalten.

Was fehlt, von hier aus gesehen

Der vollständige Überblick über Kommandozeilen-Code-Agenten, Stärken und Schwächen gegenüber Claude Code, Codex, Gemini CLI und den anderen, wird separat in unserem eigenen Vergleich behandelt. Die Liste der Skills und die aufgelöste Konfiguration sind nur über Diagnosebefehle zugänglich, debug skill und debug config. Beide fehlen im Hauptmenü: nützlich, sobald man sie kennt, aber nicht wirklich auffindbar. Die lokale Speicherung ist durchaus real: Sitzung, Nachrichten und Werkzeugaufrufe leben in einer SQLite-Datenbank auf deiner Festplatte, also ist „keine an die Server von Anomaly gesendeten Daten“ nicht gleichbedeutend mit „nichts wird geschrieben“. Und der kostenlose Zugang endet beim hauseigenen Modell: Beim ersten Markenmodell trifft man auf dasselbe Konto und dieselbe Bankkarte, die man auch anderswo fände.

Was du dir merken solltest

• OpenCode (Anomaly, MIT-Lizenz) installiert sich, ohne etwas auf dem System zu hinterlassen, über npm install opencode-ai --prefix und ein HOME isoliert, getestete Version: 1.18.29.
• Die Konfiguration wird auf drei zusammengeführten Ebenen gelesen: Projekt (aufwärts bis zur Git-Wurzel), global (~/.config/opencode, niemals ~/.opencode), und externe Skills, automatisch geladen aus ~/.claude/skills und ~/.agents/skills.
• HOME zu isolieren funktioniert, vorausgesetzt man exportiert es bei jedem Befehl. Ein Vergessen verbindet OpenCode wieder mit deinem echten persönlichen Verzeichnis, Skills anderer Tools eingeschlossen: zwei Köder-Skills bestätigen es, und eine Auflistung ohne HOME fördert 120 davon zutage.
• Ein Projekt-Skill und ein lokales MCP-Werkzeug funktionieren schon beim ersten Versuch zusammen, ohne Zugangsdaten, mit dem kostenlosen Modell big-pickle von OpenCode Zen.
• ask-Berechtigungen werden im nicht interaktiven Modus automatisch abgelehnt, aber der Exit-Code bleibt 0: zu beachten, wenn du Prüfungen um opencode run herum skriptest.
• Die lokalen Modelle (Ollama, llama.cpp, LM Studio) laufen über einen von Hand zu deklarierenden generischen OpenAI-kompatiblen Anbieter, nicht über eine dedizierte Ollama-Integration.