Ein Issue kommt rein, und statt es selbst aufzumachen, schreibt ihr einen Kommentar: /oc fix this. Ein paar Minuten später liegt ein Pull Request mit der Änderung da. Genau das macht die OpenCode GitHub Action. Der Coding Agent läuft dabei in eurem eigenen GitHub Actions Runner. Hier steht, wie ihr die Action einrichtet, wie ihr Modell und Rechte festlegt und wo ihr vorsichtig sein solltet.
NCA KI Workshop für Developer: Euer Team lernt Agentic Coding mit OpenCode, von der lokalen Session bis zur Pipeline, mit Regeln und Quality Gates für die Produktion. Zum KI Workshop für Developer
Was die OpenCode GitHub Action kann
Die Action reagiert auf Kommentare mit /opencode oder /oc. Sie liest das Issue oder den Pull Request samt Kommentaren und arbeitet dann los. Drei Dinge kann sie gut:
- Issues erklären: OpenCode liest den Thread und antwortet mit einer klaren Zusammenfassung.
- Fixes umsetzen: OpenCode legt einen neuen Branch an, ändert den Code und öffnet einen Pull Request.
- Pull Requests überarbeiten: Ein Kommentar im Pull Request oder direkt an einer Codezeile reicht, und OpenCode committet die Änderung in denselben Pull Request.
Alles läuft in eurem GitHub Actions Runner. Der Code verlässt das Repository nur in Richtung des Modells, das ihr selbst auswählt.
Die OpenCode GitHub Action mit einem Befehl einrichten
Der schnellste Weg läuft über das Terminal. Geht in ein Projekt, das schon auf GitHub liegt, und startet:
opencode github installDer Befehl führt euch durch drei Schritte: GitHub App installieren, Workflow anlegen und Secrets setzen. Wer lieber selbst Hand anlegt, installiert die App unter github.com/apps/opencode-agent und legt den Workflow manuell an.
Der Workflow für Kommentare in Issues und Pull Requests
Der Workflow liegt unter .github/workflows/opencode.yml. Er startet nur, wenn ein Kommentar /oc oder /opencode enthält:
name: opencode
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
jobs:
opencode:
if: |
contains(github.event.comment.body, '/oc') ||
contains(github.event.comment.body, '/opencode')
runs-on: ubuntu-latest
permissions:
id-token: write
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 1
persist-credentials: false
- uses: anomalyco/opencode/github@latest
env:
EUER_API_KEY: ${{ secrets.EUER_API_KEY }}
with:
model: anbieter/modellEUER_API_KEY und anbieter/modell sind Platzhalter. Welchen Variablennamen euer Anbieter erwartet und wie das Modell heißt, steht in der OpenCode Doku zu Providern.
Modell und API Key festlegen
Das Feld model ist Pflicht. Es hat immer die Form Anbieter, Schrägstrich, Modell. Den API Key legt ihr in den Settings des Repositorys unter Secrets and variables und dann Actions ab. Im Workflow steht nur der Verweis auf das Secret, nie der Key selbst.
Wir nutzen OpenCode mit Open Weight Modellen aus den Familien GLM und Qwen, zum Beispiel über Z.AI oder Ollama Cloud. Für Reviews und kleine Fixes reicht das sehr gut. Mit dem optionalen Feld variant stellt ihr bei manchen Anbietern ein, wie viel das Modell nachdenken soll. Welche Modelle sich für welche Aufgabe eignen, vergleichen wir bei den Vibe Coding Modellen.
Welche Ereignisse OpenCode starten können
| Ereignis | Auslöser | Hinweis |
|---|---|---|
| issue_comment | Kommentar in Issue oder Pull Request | Braucht /oc oder /opencode im Kommentar |
| pull_request_review_comment | Kommentar an einer Codezeile | OpenCode bekommt Datei, Zeilen und Diff |
| issues | Issue angelegt oder bearbeitet | Braucht einen festen Prompt |
| pull_request | Pull Request geöffnet oder aktualisiert | Ohne Prompt macht OpenCode ein Review |
| schedule | Zeitplan per Cron | Braucht einen festen Prompt |
| workflow_dispatch | Manueller Start im Actions Tab | Braucht einen festen Prompt |
Automatische Reviews für jeden Pull Request
Mit dem Ereignis pull_request bekommt jeder neue Pull Request ein Review, ohne dass jemand einen Kommentar schreibt. Hier reichen Leserechte. Die Variante mit use_github_token nutzt das normale Token des Workflows und kommt ohne die OpenCode App aus:
name: opencode-review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: actions/checkout@v6
with:
persist-credentials: false
- uses: anomalyco/opencode/github@latest
env:
EUER_API_KEY: ${{ secrets.EUER_API_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
model: anbieter/modell
use_github_token: true
prompt: |
Prüfe diesen Pull Request auf Fehler,
Sicherheitslücken und fehlende Tests.
Antworte kurz und konkret.Ein KI Review ersetzt kein menschliches Review. Es fängt aber viele kleine Fehler ab, bevor ein Mensch Zeit investiert. Und es läuft zusätzlich zu euren Tests und Quality Gates, nicht statt ihnen.
Rechte im Runner klein halten
Ein Agent, der Branches anlegt und Pull Requests öffnet, braucht Schreibrechte. Gebt sie nur dort, wo sie wirklich gebraucht werden. Wie ihr Rechte lokal einstellt, steht in OpenCode Permissions richtig einstellen.
- Mit Reviews starten: Fangt mit Leserechten und Kommentaren an. Schreibrechte kommen erst, wenn ihr dem Ablauf vertraut.
- Checkout ohne gespeicherte Zugangsdaten:
persist-credentials: falseverhindert, dass das Token im Arbeitsordner liegen bleibt. - Öffentliche Repositorys schützen: Dort kann jeder kommentieren. Filtert zum Beispiel nach dem Alter des Accounts oder der Rolle der Person, bevor OpenCode startet.
- Eigene Auslöser: Mit dem Feld
mentionslegt ihr eigene Trigger Wörter fest. - Keine Secrets im Code: API Keys nur als Secret, nie im Workflow oder in der AGENTS.md.
Alle Optionen und Beispiele stehen in der OpenCode Doku zu GitHub. Wie ihr Secrets anlegt, erklärt die GitHub Doku zu Secrets in Actions.
Beispiele für Kommentare mit oc
/opencode explain this issueliest den ganzen Thread und erklärt ihn./opencode fix thislegt einen Branch an, setzt den Fix um und öffnet einen Pull Request./oc add error handling hereals Kommentar an einer Codezeile ändert genau diese Stelle.- Ein Kommentar im Pull Request wie „Lösche den Anhang auch im Speicher /oc“ landet als Commit im selben Pull Request.
Gute Issues führen zu guten Ergebnissen. Schreibt hinein, was passieren soll, wo der Fehler auftritt und woran man erkennt, dass er behoben ist. Wie der Weg vom Ticket zum Agent auch auf dem Desktop aussieht, zeigt der Beitrag zur GitKraken Agent Session aus dem Issue.
Wie wir Teams beim Agent in der Pipeline begleiten
OpenCode ist bei uns der Coding Agent im Alltag, lokal und in der Pipeline. Ein Agent in GitHub bringt nur dann etwas, wenn Tests und Quality Gates seine Arbeit prüfen. Warum das mit jedem Modell wichtiger wird, steht in KI Guardrails und bessere Modelle. Wie Tests das absichern, zeigt End to End Tests für jedes Webprojekt.
Den Überblick über OpenCode, Astro und GitHub Pages geben unsere Vibe Coding Tipps und Tricks. Pipelines für KI Code beschreiben wir bei den Vibe Coding CI/CD Pipelines. Git Kontext direkt im Agent liefert der GitKraken MCP Server für OpenCode. Begleitung im Projekt gibt es in der Vibe Coding Beratung. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
Häufige Fragen zur OpenCode GitHub Action
Wie richte ich die OpenCode GitHub Action 2026 ein?
Startet im Projekt den Befehl opencode github install. Er installiert die GitHub App, legt den Workflow an und richtet die Secrets ein. Alternativ installiert ihr die App von Hand und legt die Datei .github/workflows/opencode.yml selbst an. Danach reagiert OpenCode auf Kommentare mit /oc oder /opencode.
Welches Modell nutzt die OpenCode GitHub Action 2026?
Das legt ihr selbst fest. Das Feld model ist Pflicht und hat die Form Anbieter, Schrägstrich, Modell. Den API Key eures Anbieters speichert ihr als Secret im Repository. Für Reviews und kleine Fixes reichen Open Weight Modelle wie GLM oder Qwen gut aus.
Kann OpenCode 2026 automatisch jeden Pull Request prüfen?
Ja. Mit dem Ereignis pull_request startet OpenCode bei jedem neuen oder geänderten Pull Request. Ohne eigenen Prompt macht es ein Review. Für reine Reviews reichen Leserechte auf den Inhalt. Das KI Review ergänzt menschliche Reviews und eure Tests, ersetzt sie aber nicht.
Wo läuft die OpenCode GitHub Action 2026?
Sie läuft in eurem GitHub Actions Runner. Der Code wird dort ausgecheckt und bearbeitet. Nach außen geht nur die Anfrage an das Modell, das ihr ausgewählt habt. Wer Code nicht an externe Modelle geben darf, braucht einen Anbieter, der zu den eigenen Datenschutzregeln passt.
Brauche ich die OpenCode App für GitHub?
Nicht zwingend. Mit use_github_token true nutzt die Action das normale Token des Workflows. Dann braucht ihr die App nicht, müsst aber die nötigen Rechte im Workflow selbst vergeben. Für Kommentare in Issues mit Branches und Pull Requests ist die App der einfachere Weg.
Ist die OpenCode GitHub Action für öffentliche Repositorys sicher?
Nur mit zusätzlichen Filtern. In öffentlichen Repositorys kann jeder kommentieren und damit Kosten und Änderungen auslösen. Prüft vor dem Start zum Beispiel das Alter des Accounts oder die Rolle der Person. Und startet mit Reviews, bevor ihr Schreibrechte vergebt.
OpenCode in eurer Pipeline, sicher eingerichtet
Wir richten OpenCode in GitHub mit passenden Rechten, Reviews und Quality Gates für euer Team ein, oder eure Developer lernen es im KI Workshop selbst. Das Vorgespräch ist kostenlos, abgerechnet wird transparent nach Minuten.
