NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüner Werkzeugkasten mit Puzzleteilen und Schriftzug OpenCode Plugins

Was sind OpenCode Plugins?

OpenCode Plugins sind JavaScript oder TypeScript Module, die sich in Events des Coding Agents einklinken und sein Verhalten verändern. Sie fügen neue Tools hinzu, binden externe Dienste an oder blockieren gefährliche Aktionen, bevor sie passieren.

Ein Plugin exportiert eine Funktion. Die Funktion bekommt Projektkontext und einen SDK Client und gibt ein Objekt mit Hooks zurück. Mehr braucht es nicht. Genau diese Schlichtheit hat 2026 ein Ökosystem mit mehreren Dutzend nützlichen Erweiterungen entstehen lassen.

Der Unterschied zu Claude Code Plugins ist wichtig: Dort steckt ein eigenes Manifest Format dahinter. Bei OpenCode ist ein Plugin einfach Code, der beim Start geladen wird. Das macht Portierungen möglich, aber nicht automatisch.

Inhalt

OpenCode Plugins mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet täglich mit OpenCode und Claude Code im echten Projektbetrieb. Symfony, PHP, Astro, Cypress. Unsere Modelle laufen lokal über Ollama, dazu Cloud Modelle wenn es sein muss. Wir kennen die Plugin API nicht aus der Dokumentation, sondern aus eigenen Hooks, die Secrets schützen und Testläufe erzwingen.

Wir helfen Teams beim Vibe Coding Onboarding und beim Aufräumen danach. Dazu gehören ein Codebase Audit für KI generierten Code, ein Vibe Coding Security Audit vor dem Livegang und DSGVO Beratung, wenn die Datenfrage im Raum steht. Wer sein Projekt schon an die Wand gefahren hat, findet Hilfe unter Vibe Coding Projekt retten. Die Basis dazu liefert unser Vibe Coding Consulting.

OpenCode im Team sauber aufsetzen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Plugins, Skills, Agents und Commands: der Unterschied

OpenCode kennt vier Erweiterungsarten. Wer sie verwechselt, sucht die Lösung an der falschen Stelle.

  • Plugins erweitern, was der Agent kann. Sie hängen sich an Events, fügen eigene Tools hinzu oder blockieren Aktionen.
  • Skills erweitern, was der Agent weiß. Sie sind wiederverwendbare Anleitungen im SKILL.md Format, etwa für Code Reviews oder Release Checklisten.
  • Agents sind spezialisierte Rollen als Markdown Datei mit eigenen Toolrechten, abgelegt unter .opencode/agents/.
  • Commands sind gespeicherte Prompts, die du per Slash aufrufst, abgelegt unter .opencode/commands/.

Die Faustregel ist kurz: Skills bringen dem Agenten etwas bei, Plugins geben ihm neue Fähigkeiten. Ein Skill sagt dem Agenten, wie er ein Review führt. Ein Plugin verbindet ihn mit GitHub, damit er den Pull Request überhaupt lesen kann.

In der Praxis brauchst du beides. Das Agent Skills Ökosystem verteilt Konventionen über Toolgrenzen hinweg, Plugins bleiben werkzeugspezifisch.

Die Plugin API: so sieht ein OpenCode Plugin aus

Ein Plugin ist eine async Funktion. Sie bekommt einen Kontext und gibt Hooks zurück. Der Kontext enthält project, directory, worktree, einen SDK client und $ für Shell Befehle über die Bun Shell API.

Code: 
          
import type { Plugin } from "@opencode-ai/plugin"

export const MyPlugin: Plugin = async ({ project, client, $, directory, worktree }) => {
  return {
    // Hooks kommen hier rein
  }
}

Das wohl nützlichste Beispiel aus der offiziellen Dokumentation schützt Secrets. Der Hook tool.execute.before läuft, bevor ein Tool ausgeführt wird. Wirft er einen Fehler, ist die Aktion abgebrochen.

Code: 
          
export const EnvProtection = async () => {
  return {
    "tool.execute.before": async (input, output) => {
      if (input.tool === "read" && output.args.filePath.includes(".env")) {
        throw new Error("Do not read .env files")
      }
    },
  }
}

Genau das ist der Punkt, an dem Plugins interessant werden. Ein Agent, der eigenständig Dateien liest und Befehle ausführt, braucht Grenzen. Wir nennen das Guardrails, und ein Plugin ist die einfachste Stelle, sie zu setzen.

Events: die Hooks im Überblick

OpenCode stellt Events aus neun Bereichen bereit. Sie decken den kompletten Lebenszyklus einer Session ab, von der Erstellung über Toolaufrufe und Dateiänderungen bis zur Kompaktierung des Kontexts. Die Tabelle zeigt, welche Gruppe wofür taugt.

OpenCode Event Gruppen und ihr Einsatzzweck

Gruppe Events Typischer Einsatz
Tool tool.execute.before, tool.execute.after Secrets schützen, Befehle escapen, Ergebnisse protokollieren
Session session.created, session.idle, session.error, session.compacted, session.diff, session.status Benachrichtigungen, Metriken, Abschlussprüfungen
File file.edited, file.watcher.updated Formatter anstoßen, Änderungen tracken
Permission permission.asked, permission.replied Freigaben auditieren, Policies durchsetzen
LSP lsp.client.diagnostics, lsp.updated Typfehler direkt zurück in den Agenten spielen
Shell shell.env Umgebungsvariablen für alle Shell Aufrufe injizieren
TUI tui.prompt.append, tui.command.execute, tui.toast.show Oberfläche steuern, Hinweise einblenden
Message und Todo message.updated, message.part.updated, todo.updated Fortschritt spiegeln, externe Boards synchronisieren
Command und Server command.executed, server.connected, installation.updated Nutzung messen, Startlogik anhängen

Custom Tools: eigene Werkzeuge für den Agenten

Plugins können nicht nur reagieren, sondern dem Agenten eigene Tools geben. Der tool Helper nimmt eine Beschreibung, ein Zod Schema für die Argumente und eine Ausführungsfunktion.

Code: 
          
import { type Plugin, tool } from "@opencode-ai/plugin"

export const CustomToolsPlugin: Plugin = async (ctx) => {
  return {
    tool: {
      mytool: tool({
        description: "This is a custom tool",
        args: {
          foo: tool.schema.string(),
        },
        async execute(args, context) {
          const { directory, worktree } = context
          return `Hello ${args.foo} from ${directory}`
        },
      }),
    },
  }
}

Wichtig: Trägt ein Plugin Tool denselben Namen wie ein eingebautes Tool, gewinnt das Plugin. Damit lässt sich Standardverhalten gezielt ersetzen, etwa ein eigenes Testkommando statt eines generischen Shell Aufrufs.

Ein zweiter, oft übersehener Hebel ist experimental.session.compacting. Der Hook läuft, bevor OpenCode eine lange Session zusammenfasst. Du kannst zusätzlichen Kontext einschieben oder den Prompt komplett ersetzen. Bei langen Refactorings verhindert das den klassischen Gedächtnisverlust mitten in der Arbeit.

Code: 
          
export const CompactionPlugin = async () => {
  return {
    "experimental.session.compacting": async (input, output) => {
      output.context.push("Aktueller Task, offene Dateien und getroffene Entscheidungen")
    },
  }
}

Plugins installieren: npm oder lokale Datei

Es gibt zwei Wege. Lokale Plugins legst du als JavaScript oder TypeScript Datei ab. Projektbezogen unter .opencode/plugins/, global unter ~/.config/opencode/plugins/. Beim Start werden sie automatisch geladen.

npm Pakete trägst du in die Konfiguration ein. OpenCode installiert sie beim Start mit Bun und cached sie unter ~/.cache/opencode/node_modules/.

Code: 
          
{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["opencode-wakatime", "@my-org/custom-plugin"]
}

Die Ladereihenfolge ist festgelegt: erst globale Konfiguration, dann Projektkonfiguration, dann globales Plugin Verzeichnis, zuletzt das Projektverzeichnis. Alle Hooks laufen nacheinander. Ein lokales Plugin und ein npm Plugin mit ähnlichem Namen werden beide geladen, das ist eine typische Fehlerquelle.

Braucht ein lokales Plugin externe Pakete, legst du eine package.json in dein Konfigurationsverzeichnis. OpenCode führt beim Start bun install aus.

Code: 
          
{
  "dependencies": {
    "shescape": "^2.1.0"
  }
}

Die besten OpenCode Plugins 2026

Das Ökosystem wächst schnell. Die kuratierte Liste awesome-opencode führt inzwischen mehrere Dutzend Plugins, Themes und Agents. Nicht alles davon ist im engen Sinn ein Plugin: manches sind MCP Server, manches Skills. Für die tägliche Arbeit haben sich einige Kandidaten herausgeschält.

oh-my-opencode gilt als das umfangreichste Projekt im Ökosystem. Es bringt Background Agents, vorgefertigte LSP und AST Tools, MCP Anbindung, kuratierte Agent Packs und Kompatibilität zu Claude Code mit. Es gibt eine schlanke Variante für alle, denen das Vollpaket zu viel ist.

opencode-supermemory gibt dem Agenten Gedächtnis über Sessions und Projekte hinweg. Wer sich daran gewöhnt hat, jedem Chat wieder zu erklären, dass das Repo pnpm nutzt und dieser Ordner tabu ist, versteht den Wert sofort. Wie das Thema grundsätzlich funktioniert, zeigt unser Beitrag zu KI Memory gegen KI Amnesie.

opencode-pty bringt echte Pseudoterminals. Der Agent startet Hintergrundprozesse, schickt später Eingaben nach und liest das Ergebnis. Für Dev Server, Watch Modi und lange Testläufe ist das der Unterschied zwischen brauchbar und ärgerlich.

Dynamic Context Pruning räumt lange Sessions auf. Alte Toolausgaben werden durch Platzhalter ersetzt, bevor der Request rausgeht. Die Sessionhistorie selbst bleibt unangetastet, nur der Prompt schrumpft. Bei großen Repos senkt das die Tokenkosten spürbar.

opencode-agent-skills lädt Skills aus Projektordnern, Nutzerverzeichnissen und Claude kompatiblen Pfaden. Wer aus dem Claude Code Umfeld kommt und seine Skill Bibliothek mitnehmen will, spart sich damit viel Handarbeit.

opencode-wakatime misst, wie viel Zeit tatsächlich in KI gestützter Arbeit steckt und welche Dateien sich ändern. Für Teams, die ihren KI Einsatz belegen müssen, ist das die einfachste Datenquelle.

Dazu kommen die kleinen Helfer: opencode-notify für Systembenachrichtigungen nach langen Läufen und opencode-worktree für isolierte Sessions über Git Worktrees, damit der Agent nicht im aktuellen Branch wütet.

OpenCode Plugins nach Problem sortiert

Dein Problem Passendes Plugin Was es löst
Agent vergisst den Projektkontext opencode-supermemory Persistentes Gedächtnis über Sessions und Projekte
Kontext läuft voll, Kosten steigen Dynamic Context Pruning Alte Toolausgaben werden vor dem Request ersetzt
Lange Prozesse brechen ab opencode-pty Echte Pseudoterminals mit Nachfüttern von Eingaben
Angst um Secrets und Credentials Eigener tool.execute.before Hook Lesezugriff auf .env Dateien blockieren
Agent arbeitet im falschen Branch opencode-worktree Isolierte Sessions über Git Worktrees
Veraltete APIs im generierten Code Context7 als MCP Server Aktuelle Bibliotheksdokumentation im Kontext
Task zu groß für eine Session oh-my-opencode Background Agents, LSP und AST Tools, Agent Packs
Skills aus Claude Code übernehmen opencode-agent-skills Skills aus Claude kompatiblen Pfaden laden
Kein Überblick über den KI Einsatz opencode-wakatime Zeiten und Dateiänderungen im Dashboard
Warten auf lange Läufe opencode-notify Systembenachrichtigung bei Abschluss

Die stärksten OpenCode Features neben Plugins

Viele Teams installieren Plugins für Dinge, die OpenCode bereits eingebaut hat. Ein Blick auf die Bordmittel spart Aufwand.

Provider Freiheit. OpenCode bindet über 75 Anbieter an, von Claude über Gemini bis zu lokalen Modellen. Kein Lock in, kein Zwang zu einem Abo. Details dazu stehen in unserem Artikel zu OpenCode als Open Source Coding Agent.

MCP Server. Lokale und Remote MCP Server lassen sich direkt in der Konfiguration eintragen. Damit hängst du Context7 für aktuelle Dokumentation oder den GitHub MCP Server an, ohne eine Zeile Plugin Code zu schreiben.

LSP Integration. OpenCode spricht mit Language Servern und bekommt echte Typfehler statt Vermutungen. In getypten Projekten ist das der größte Qualitätshebel überhaupt.

Permissions und Policies. Regeln, welche Tools wann laufen dürfen, gehören in die Konfiguration. Erst wenn das nicht reicht, lohnt ein Plugin.

Agents und Commands. Rollen und wiederkehrende Prompts liegen als Markdown im Projekt. Sie sind versionierbar, reviewbar und laufen im ganzen Team gleich.

Vier Oberflächen. Terminal, Desktop App, Web und IDE Anbindung greifen auf dieselbe Session zu. Wer gerne im Terminal arbeitet, verliert nichts, wenn Kollegen die grafische Variante bevorzugen.

Claude Code Plugins nach OpenCode portieren

Direkt installieren lassen sich Claude Code Plugins nicht. Das Format mit .claude-plugin/plugin.json liest OpenCode nicht. Die einzelnen Bestandteile lassen sich aber fast immer übernehmen.

  • MCP Server sind der leichteste Fall. Die Konfiguration wandert eins zu eins in die mcp Sektion der opencode.json.
  • Skills kopierst du als SKILL.md nach .opencode/skills/. Claude spezifische Variablen musst du anpassen.
  • Agents übernimmst du als Markdown nach .opencode/agents/, mit angepasstem Frontmatter für Toolrechte.
  • Slash Commands wandern nach .opencode/commands/.
  • Hooks sind der harte Teil. Sie müssen als Plugin neu geschrieben werden.

Ein gutes Beispiel für ein Paket, das beide Welten bedient, ist Everything Claude Code. Wer Plugin Ökosysteme grundsätzlich vergleichen will, findet die Gegenüberstellung im Claude Code Plugin Marketplace.

Wichtig für alle, die von einem Fork kommen: Kilo Code basiert auf OpenCode, liest aber keine .opencode Verzeichnisse mehr. Wer Plugins zwischen beiden schiebt, muss die Pfade umstellen.

Wann sich ein Plugin lohnt und wann nicht

Die häufigste Fehlentscheidung ist, alles zu installieren, was gut klingt. Jedes Plugin läuft bei jedem Start mit, hängt sich in Events und kann Verhalten überschreiben. Ein überladenes Setup wird langsamer und schwerer zu debuggen, nicht besser.

Der bessere Weg geht vom Problem aus. Vergisst der Agent Kontext, hilft Memory. Läuft der Kontext voll, hilft Pruning. Sind Secrets im Repo, hilft ein Guard. Alles andere wartet.

Ein Punkt, der in vielen Listen fehlt: Plugins sind ausführbarer Code aus fremder Hand, der bei jedem Start automatisch installiert und geladen wird. Das ist ein klassischer Angriffsweg über die Lieferkette. Wir prüfen im Vibe Coding Security Audit genau solche Abhängigkeiten mit. Bei Plugins gilt dieselbe Sorgfalt wie bei jeder anderen npm Abhängigkeit: Quelle ansehen, Version pinnen, Updates bewusst ziehen.

Für Teams heißt das: ein gemeinsames, schlankes Set in der Projektkonfiguration, alles Persönliche im globalen Verzeichnis. So läuft die Pipeline überall gleich und niemand wundert sich über Ergebnisse, die nur auf einem Rechner entstehen.

it's crazy how much effort you can put behind things now

Dax Raad, Mitgründer und CTO OpenCode – über die Arbeit an der neuen Plugin API, via X

Unsere Erfahrung mit OpenCode im Projektalltag

Bei Never Code Alone laufen Claude Code und OpenCode nebeneinander. Der Code muss laufen, nicht nur gut aussehen. Deshalb interessiert uns an einem Plugin nicht die Featureliste, sondern was es im echten Projekt verändert.

Drei Beobachtungen aus der Praxis. Erstens: Der größte Sprung kommt nicht vom Plugin, sondern von sauberer LSP Anbindung und guten Regeln im Projekt. Zweitens: Ein einziger Guard Hook um Secrets spart mehr Ärger als zehn Komfort Plugins. Drittens: Sobald mehrere Agenten parallel arbeiten, brauchst du Worktree Isolation, sonst zerlegen sie sich gegenseitig.

Wir helfen Teams beim Aufsetzen dieser Basis. Dazu gehört die Einordnung gegen Alternativen wie Claude Code und Crush, die Modellwahl über die Vibe Coding Modelle und strukturiertes Arbeiten mit OpenSpec. Wer erst einsteigt, findet den Weg unter Vibe Coding lernen. Alle weiteren Begriffe stehen im NCA Glossar für KI Tools 2026.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

NCA Vibe Coding Consulting

Roland Golla ist Entwickler aus Leidenschaft – seit über 20 Jahren. Er hat hunderte Projekte begleitet, von Legacy-Refactoring bis KI-Integration. Bei Vibe Coding verbindet er das Beste aus beiden Welten: Die Geschwindigkeit von KI-generiertem Code mit der Qualität professioneller Softwareentwicklung. Kein Bullshit, keine Agentur-Floskeln – direkte Hilfe von jemandem, der selbst täglich im Code steckt.

E-Mail Kontakt

Häufige Fragen zu OpenCode Features und Plugins

Die Fragen, die uns zu OpenCode Erweiterungen am häufigsten erreichen.

Was sind die besten OpenCode Plugins 2026?

Es gibt keine allgemeingültige Top Liste, sondern passende Antworten auf konkrete Probleme. Für Gedächtnis über Sessions hinweg opencode-supermemory, für Tokenkosten Dynamic Context Pruning, für lange Prozesse opencode-pty, für große Aufgaben oh-my-opencode. Wer nur eines installiert, sollte mit dem Plugin starten, das den größten täglichen Reibungspunkt löst.

Wie installiere ich ein OpenCode Plugin 2026?

Zwei Wege. Lokale Plugins legst du als JavaScript oder TypeScript Datei unter .opencode/plugins/ im Projekt oder unter ~/.config/opencode/plugins/ global ab. npm Pakete trägst du im plugin Array der opencode.json ein. OpenCode installiert sie beim Start automatisch mit Bun und cached sie unter ~/.cache/opencode/node_modules/.

Welche Events bietet die Plugin API 2026?

OpenCode gruppiert seine Events in neun Bereiche: Command, File, Installation, LSP, Message, Permission, Server, Session, Todo, Shell, Tool und TUI. Am meisten genutzt werden tool.execute.before für Guardrails, session.idle für Benachrichtigungen und file.edited für nachgelagerte Prüfungen. Dazu kommt der Hook experimental.session.compacting für eigenen Kontext beim Zusammenfassen.

Kann ich Claude Code Plugins in OpenCode nutzen 2026?

Nicht direkt. OpenCode liest das Manifest Format mit .claude-plugin/plugin.json nicht. Die Bestandteile lassen sich aber übernehmen: MCP Server wandern in die mcp Sektion der opencode.json, Skills als SKILL.md nach .opencode/skills/, Agents und Commands als Markdown in die entsprechenden Verzeichnisse. Nur Hooks musst du als Plugin neu schreiben.

Was ist der Unterschied zwischen Plugins und Skills 2026?

Skills sind wiederverwendbare Anleitungen. Sie bringen dem Agenten bei, wie er eine Aufgabe angeht, etwa ein Code Review nach Teamcheckliste. Plugins sind Erweiterungen. Sie geben dem Agenten neue Fähigkeiten oder ändern sein Verhalten, etwa eine Anbindung an GitHub oder eine Sperre für Secrets. In der Praxis brauchst du beides.

Brauche ich überhaupt Plugins für OpenCode?

Oft nicht sofort. Viele Anforderungen deckt OpenCode bereits ab: MCP Server, LSP Anbindung, Agents, Commands, Permissions und Policies stehen in der Konfiguration. Erst wenn du Verhalten brauchst, das sich nicht konfigurieren lässt, etwa das Blockieren bestimmter Dateizugriffe, führt der Weg zum Plugin.

Wie schreibe ich ein eigenes OpenCode Plugin?

Du exportierst eine async Funktion aus einer TypeScript Datei. Sie bekommt project, directory, worktree, einen SDK client und die Bun Shell API $. Zurück gibt sie ein Objekt mit Hooks. Für Typsicherheit importierst du den Plugin Typ aus @opencode-ai/plugin. Für ein erstes Plugin reichen zehn Zeilen.

Wie füge ich eigene Tools hinzu?

Über den tool Helper aus @opencode-ai/plugin. Er nimmt eine Beschreibung, ein Zod Schema für die Argumente und eine execute Funktion. Das Tool steht dem Agenten dann neben den eingebauten Werkzeugen zur Verfügung. Trägt es denselben Namen wie ein eingebautes Tool, hat das Plugin Vorrang.

Wie schütze ich Secrets vor dem Agenten?

Mit einem Hook auf tool.execute.before. Prüfe, ob das Tool read heißt und der Pfad .env enthält, und wirf dann einen Fehler. Damit ist der Zugriff sauber abgebrochen. Wichtiger als jedes Plugin bleibt trotzdem, dass produktive Credentials gar nicht erst im Arbeitsverzeichnis liegen.

Sind OpenCode Plugins ein Sicherheitsrisiko?

Sie sind fremder Code, der bei jedem Start automatisch installiert und ausgeführt wird. Das ist derselbe Angriffsweg wie bei jeder npm Abhängigkeit. Prüfe die Quelle, pinne Versionen und zieh Updates bewusst. In Projekten mit echten Zugangsdaten gehört diese Prüfung in den regulären Reviewprozess.

Wie reduziere ich Tokenkosten in langen Sessions?

Zwei Hebel. Dynamic Context Pruning ersetzt alte Toolausgaben durch Platzhalter, bevor der Request rausgeht, ohne die Sessionhistorie zu verändern. Und der Hook experimental.session.compacting erlaubt dir, beim Zusammenfassen genau den Kontext mitzugeben, der wirklich zählt: aktueller Task, offene Dateien, getroffene Entscheidungen.

Wie verwalte ich Plugins im Team?

Trenne strikt. Was alle brauchen, gehört in die opencode.json im Repository und ist damit versioniert und reviewbar. Was persönlich ist, etwa Benachrichtigungen oder Zeiterfassung, gehört ins globale Verzeichnis. So erzeugt die Pipeline überall dieselben Ergebnisse und niemand debuggt Unterschiede, die aus einer lokalen Installation stammen.