OpenTag auf einem VPS selbst hosten und absichern

Was OpenTag beim Erwähnen eines Agenten macht

OpenTag wandelt eine @mention in einem Slack-Thread oder einem GitHub-Issue in einen Lauf eines Coding-Agenten auf einer von Ihnen verwalteten Maschine um. Jemand kommentiert @opentag investigate this in einem Issue. Ein Listener empfängt das Plattformereignis, prüft dessen Signatur, ordnet die Erwähnung einem verknüpften Projekt zu, startet den Coding-Agenten gegen einen lokalen Checkout und veröffentlicht das Ergebnis im selben Thread.

Das Projekt steht unter der MIT-Lizenz und befindet sich unter amplifthq/opentag. Im August 2026 ist v0.9.0 die neueste getaggte Version; sie wurde am 28. Juli 2026 veröffentlicht und als npm-Paket bereitgestellt. Es gibt kein offizielles Container-Image. Daher pinnen Sie die npm-Version. Jeder folgende Befehl pinnt diese Version.

Dadurch wird das Projekt wegen der GitHub-Seite zu einem VPS-Projekt und nicht zu einem Laptop-Projekt. GitHub liefert Repository-Ereignisse aus, indem es eine HTTP-Anfrage an eine URL sendet, die Sie einmal registrieren. Diese URL muss daher auch morgen unter derselben Adresse erreichbar sein.

Die vier Komponenten

Der Listener empfängt Plattformereignisse. Jede Plattform hat einen eigenen Listener. Der GitHub-Listener ist ein HTTP-Endpunkt auf Port 3050 unter dem Pfad /github/webhooks. Der Listener für die Slack Events API läuft auf Port 3040 unter /slack/events. Slack kann auch im Socket Mode betrieben werden. Dabei öffnet die Anwendung eine ausgehende WebSocket-Verbindung und benötigt überhaupt keinen eingehenden Port.

Der Dispatcher koordiniert den Ablauf. Standardmäßig überwacht er Port 3030, speichert den Ausführungsstatus in einer lokalen Datenbankdatei, die über OPENTAG_DATABASE_PATH festgelegt wird, und protokolliert für jede Ausführung einen Audit-Trail. Dieser Port darf niemals von außerhalb des Servers erreichbar sein.

Der Runner ist der lokale Daemon. Er fragt regelmäßig nach Arbeit, übernimmt eine Ausführung, hält dafür eine Lease und sendet standardmäßig alle 15 Sekunden einen Heartbeat, solange die Ausführung aktiv ist. Er lehnt jede übernommene Ausführung ab, deren Projektziel fehlt oder außerhalb der Allowlist in seiner eigenen Konfiguration liegt. Diese Prüfung verhindert, dass ein GitHub-Ereignis Ihren Agent auf ein Repository verweist, das Sie nicht zugeordnet haben.

Der Executor ist der Coding-Agent selbst. OpenTag startet ihn über ACP (agent client protocol), ein JSON-RPC-Protokoll über die Standardeingabe und -ausgabe. Dadurch läuft der Agent als untergeordneter Prozess in einem Arbeitsverzeichnis, das OpenTag ihm übergibt. Zu den integrierten Namen gehören echo, codex, claude-code, cursor, opencode, hermes und openclaw. Beginnen Sie mit echo, dem Executor aus der Beispielkonfiguration. Damit können Sie prüfen, ob der gesamte Ablauf funktioniert, bevor ein Modell Ihren Code verändert.

Die Reihenfolge bleibt immer gleich: Plattformereignis, Signaturprüfung, Ausführungsdatensatz, Übernahme, Agent, Antwort im Thread.

Warum ein Laptop und ein Tunnel nicht ausreichen

Die GitHub-Einrichtungsanleitung fordert Sie auf, ngrok http 3050 auszuführen und den Tunnel-Host in den Repository-Webhook einzutragen. Das funktioniert in den ersten zehn Minuten. Der Host eines kostenlosen Tunnels ändert sich bei jedem Neustart des Prozesses und ist nicht mehr verfügbar, sobald der Laptop in den Ruhezustand wechselt. GitHub behält die alte Payload-URL und versucht weiterhin, sie zu verwenden. Dadurch füllt sich der Tab „Recent Deliveries“ in den Webhook-Einstellungen mit Fehlern, während der Thread stumm bleibt. Eine Woche lang bemerkt das niemand, weil ein Webhook, der nichts tut, genauso aussieht wie ein Bot, den niemand erwähnt hat.

Ein VPS behebt die beiden Ursachen. Der DNS-Name ändert sich nicht. Die einmal eingetragene Payload-URL bleibt daher korrekt. Die Maschine wechselt nicht in den Ruhezustand. Dadurch erhält ein Kommentar um 02:00 eine Antwort. Richten Sie das System zuerst ordnungsgemäß ein: die ersten zehn Minuten auf einem neuen VPS behandeln den Anmeldebenutzer und die Firewall, die diese Anleitung voraussetzt.

Slack ist die Ausnahme. Im Socket Mode baut Slack die Verbindung nach außen auf und benötigt keine öffentliche URL. Eine Bereitstellung ausschließlich für Slack kann daher geschlossen bleiben. Für GitHub gibt es keine gleichwertige Option. Repository-Webhooks verwenden eingehendes HTTP. Dafür sind ein öffentlicher Endpunkt, TLS (Transport Layer Security) und eine Signaturprüfung erforderlich.

Self-host OpenTag unter Ubuntu aus einem festgelegten Release

OpenTag v0.9.0 erfordert Node.js 22 oder neuer. Ubuntu 24.04 liefert im eigenen Repository Node 18 aus. Installieren Sie Node.js daher aus dem NodeSource-Repository.

curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v muss v22 oder höher ausgeben. Unter Node 20 gibt das Setup eine EBADENGINE-Warnung aus. Die CLI kann anschließend beim Start fehlschlagen.

Geben Sie dem Dienst ein eigenes Konto. Der Agent läuft mit den Berechtigungen dieses Benutzers. Verwenden Sie daher weder Ihr Anmeldekonto noch root. Benutzer mit minimalen Berechtigungen auf einem VPS erläutert, warum diese Trennung den zusätzlichen Schritt rechtfertigt.

sudo adduser --disabled-password --gecos "" opentag
sudo loginctl enable-linger opentag
sudo npm install -g @opentag/cli@0.9.0
command -v opentag

command -v opentag sollte einen Pfad wie /usr/bin/opentag ausgeben. Die Linger-Einstellung ist unter Linux wichtig: OpenTag installiert seinen Hintergrunddienst über systemd. Ein Benutzerdienst ohne Linger wird beendet, sobald Ihre SSH-Sitzung geschlossen wird.

Führen Sie das Setup als dieser Benutzer aus.

sudo -iu opentag opentag setup

Das Setup fragt sechs Dinge ab: die Sprache der CLI, die lokale Listening-Adresse, den Coding-Agent, das lokale Projekt, an dem gearbeitet werden soll, die zu speichernden Plattformanmeldedaten und die Ausführungsart. Belassen Sie die Listening-Adresse bei 127.0.0.1. nginx übernimmt die TLS-Terminierung und leitet den Verkehr dorthin weiter. Die Listener müssen daher nicht von außen erreichbar sein. Für GitHub werden außerdem das Repository im Format owner/repo, die Berechtigung zum Öffnen von Pull Requests, der Webhook-Port (standardmäßig 3050) und das Token abgefragt. Wählen Sie am Ende den Modus für den Hintergrunddienst. Wenn bereits eine Konfiguration vorhanden ist und der Dienst ohne Rückfragen installiert werden soll, erledigt opentag setup --service dies.

Die Konfiguration wird unter /home/opentag/.config/opentag/config.json gespeichert. Der Laufzeitstatus liegt unter /home/opentag/.local/state/opentag. Prüfen Sie diese Schlüssel nach dem Schreiben der Datei manuell.

{
  "runnerId": "runner_local",
  "dispatcherUrl": "http://localhost:3030",
  "runnerToken": "...",
  "approvalMode": "ask",
  "repositories": []
}

Bevorzugen Sie runnerToken, das an den Runner gebundene Bearer-Token, gegenüber dem älteren gemeinsam verwendeten pairingToken. Die Konfigurationsdatei enthält Anmeldedaten im Klartext, sofern Sie sie nicht durch einen Secret-Verweis ersetzen. Dieser liest den Wert beim Start aus der Umgebung oder aus einer Datei auf dem Datenträger. In beiden Fällen ist diese Datei das sensibelste Objekt auf dem System: Modus 600, Eigentümer opentag und niemals innerhalb eines Git-Repositorys. Die weitergehende Begründung finden Sie unter Secrets aus AI-Agents heraushalten.

Prüfen Sie die Installation, bevor Sie etwas erreichbar machen.

sudo -iu opentag opentag doctor
sudo -iu opentag opentag status

opentag doctor prüft den Dispatcher, die Bindings, die Checkouts und die Executoren. opentag status gibt die Konfiguration und den Laufzeitstatus aus. Sobald Runs vorhanden sind, kann die Ausgabe auf einen einzelnen Run eingeschränkt werden. Beheben Sie alle von doctor gemeldeten Probleme, bevor Sie eine Plattform auf dieses System verweisen.

TLS vorschalten und nur zwei Pfade öffnen

Nginx beendet TLS und leitet genau zwei Pfade weiter. Alle anderen Anfragen liefern 404. Ein Scanner, der den Host findet, erfährt dadurch nichts über die dahinter laufenden Dienste.

Schreiben Sie in /etc/nginx/sites-available/opentag einen einfachen Server-Block für Port 80 mit den beiden folgenden Locations. Lassen Sie anschließend Certbot den TLS-Teil ergänzen.

sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/opentag /etc/nginx/sites-enabled/opentag
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d opentag.example.com

nginx -t gibt syntax is ok und test is successful aus. Das ist die einzige Instanz zwischen einem Tippfehler und einem Reload, durch den die Website ausfällt. Certbot unter Ubuntu 24.04 mit nginx behandelt die Erneuerung und die Ursachen für Fehler bei einer ACME-Challenge (Automatic Certificate Management Environment). Der fertige Block sieht so aus.

server {
    listen 443 ssl;
    server_name opentag.example.com;

    ssl_certificate     /etc/letsencrypt/live/opentag.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/opentag.example.com/privkey.pem;

    client_max_body_size 2m;

    location = /github/webhooks {
        proxy_pass http://127.0.0.1:3050;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location = /slack/events {
        proxy_pass http://127.0.0.1:3040;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
        return 404;
    }
}

Das = in location = /github/webhooks ist eine exakte Übereinstimmung. proxy_pass ohne nachfolgende Zeichen am Port leitet die ursprüngliche URI unverändert weiter. Wenn Sie = weglassen, wird jeder Pfad unter /github/webhooks/ ebenfalls weitergeleitet. Das stellt eine größere Angriffsfläche dar, als der Listener benötigt.

Die Firewall bleibt restriktiv.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

Die Ports 3030, 3040 und 3050 werden nie geöffnet. Prüfen Sie, ob sie an Loopback und nicht an alle Interfaces gebunden sind.

sudo ss -tlnp

Jede OpenTag-Zeile sollte 127.0.0.1:3030 oder ähnlich lauten. Eine Zeile mit 0.0.0.0:3050 bedeutet, dass der Listener sich im gesamten Internet anbietet und nur ufw ihn blockiert. Ein einziger Firewall-Fehler könnte dadurch einen offenen Agent-Trigger verursachen. Grundlagen der ufw-Firewall erklärt, was diese standardmäßige Ablehnung tatsächlich bewirkt.

Zwei Prüfungen bestätigen den Zugriff über den Reverse Proxy. curl -I https://opentag.example.com/ gibt von nginx 404 zurück. Das zeigt, dass das Zertifikat gültig und der Catch-all geschlossen ist. Eine Anfrage an /slack/events oder /github/webhooks ohne Signatur darf niemals 200 zurückgeben.

Jede Signatur prüfen, weil die URL öffentlich ist

Jeder kann die Payload-URL finden. Sie steht in den Repository-Einstellungen, im Browserverlauf oder in einem Screenshot, der in ein Ticket eingefügt wurde. Die Signatur ist das einzige Merkmal, das eine echte GitHub-Zustellung von einer manuell erstellten Anfrage unterscheidet.

GitHub signiert jede Zustellung mit dem Webhook-Secret und sendet das Ergebnis im Header x-hub-signature-256. OpenTag prüft diesen Header gegen platforms.github.webhookSecret. Die Hardening-Hinweise des Projekts formulieren die Regel direkt: Akzeptieren Sie auf /github/webhooks keine unsignierten Source-Events. Slack signiert jede Anfrage mit SLACK_SIGNING_SECRET und fügt einen Zeitstempel hinzu. Dadurch kann ein aufgezeichneter Body nicht Stunden später erneut verwendet werden.

Das Weglassen dieser Prüfung ist kein geringes Risiko. Ein nicht verifizierter Endpoint akzeptiert eine manuell erstellte issue_comment-Payload mit @opentag. OpenTag startet dann mit Ihrem Token in Ihrem Checkout einen Coding-Agenten, der Anweisungen eines Fremden ausführt. Die Antwort wird an den Thread gesendet, den die gefälschte Payload angibt.

OpenTag fügt darüber hinaus zwei Schutzschichten hinzu. Source-Zustellungen werden anhand der Delivery-ID nachverfolgt. Dadurch startet die erneute Zustellung desselben Events keinen zweiten Lauf. Runner-Aufrufe akzeptieren Idempotency-Keys. Bei einer Wiederholung wird Erfolg zurückgegeben, ohne ein weiteres Audit-Event anzuhängen.

Rate Limits sind konfigurierbar und müssen aktiviert werden. OPENTAG_RATE_LIMIT_WINDOW_MS und OPENTAG_RATE_LIMIT_MAX_REQUESTS begrenzen die Anfragerate, OPENTAG_MAX_REQUEST_BODY_BYTES begrenzt die Größe des Bodys, und eine zu große Payload wird mit 413 request_body_too_large abgewiesen. OPENTAG_RATE_LIMIT_DISABLED=true ist für die lokale Entwicklung vorgesehen und hat auf einem öffentlich erreichbaren System keinen Platz. Eine weitere Regel aus denselben Hinweisen: Eine öffentliche Relay-URL muss HTTPS verwenden. Die CLI erlaubt unverschlüsseltes HTTP nur für localhost.

Welche Token-Bereiche benötigt der Bot tatsächlich?

Auf GitHub verwendet OpenTag ein fein abgestuftes Personal Access Token und keine GitHub App. In der Dokumentation steht, dass der App-Weg geplant ist und derzeit nicht die standardmäßige CLI-Konfiguration darstellt. Daraus ergibt sich eine häufig übersehene Konsequenz: Der Bot kommentiert im Namen der Person, die das Token erstellt hat. Erstellen Sie es unter einem Konto, dessen Namen Sie in jeder Triage-Antwort sehen können.

Beschränken Sie die Bereiche so weit wie im Einrichtungsleitfaden vorgesehen. Wählen Sie Only select repositories und wählen Sie ein Repository aus. Erteilen Sie Issues: Read and write sowie Pull requests: Read and write. Das reicht aus, um eine Erwähnung zu lesen und im Thread zu antworten.

Beachten Sie, was fehlt: Schreibzugriff auf den Code. OpenTag pusht keine Branches, solange preparePullRequestBranch nicht auf true gesetzt ist. Außerdem gibt es githubApplyToken, damit sich das Token zum Schreiben von Code von dem Token zum Schreiben von Kommentaren unterscheidet. Halten Sie beide getrennt. Lassen Sie das Schreib-Token deaktiviert, bis der Lese- und Kommentarpfad einige Wochen lang ausgeführt wurde.

Vermeiden Sie ein Token mit Contents: Read and write für All repositories. Jede Person, die in einem dieser Repositorys kommentieren kann, kann dann einen Agenten mit Commit-Rechten steuern. Im Audit-Protokoll erscheint dabei der Inhaber des Tokens als handelnde Person. Erweitern Sie den Geltungsbereich jeweils nur um ein Repository, nachdem sich der Agent bewährt hat.

Auf Slack lauten die Bot-Bereiche app_mentions:read, chat:write, reactions:write und channels:history. Private Channels benötigen zusätzlich groups:history sowie ein Abonnement für das Ereignis message.groups. Für den Socket Mode ist ein Token auf App-Ebene mit connections:write erforderlich, also eines, das mit xapp- beginnt. channels:history liest den Nachrichtenverlauf in den öffentlichen Channels, zu denen der Bot hinzugefügt wurde. Fügen Sie den Bot daher nur zu den gewünschten Channels hinzu und nicht zu allen.

Einen Vorgang vollständig durchlaufen lassen

Der Webhook wird zuerst eingerichtet. Öffnen Sie im Repository Settings, dann Webhooks und anschließend Add webhook. Die Payload-URL lautet https://opentag.example.com/github/webhooks, der Inhaltstyp ist application/json und das Secret ist das von der Einrichtung erzeugte. Abonnieren Sie Issue comments und Pull request review comments, und keine weiteren Ereignisse.

GitHub sendet sofort nach dem Speichern eine Ping-Zustellung. Öffnen Sie Recent Deliveries und prüfen Sie, ob die Anfrage den Server überhaupt erreicht hat. Ein 502 bedeutet dort, dass Nginx den Listener nicht erreichen konnte. Das ist ein lokales Problem und kein GitHub-Problem.

Verwenden Sie die Einrichtung jetzt. Öffnen Sie ein Issue, das einen Fehler beschreibt, und kommentieren Sie:

@opentag triage this. Reproduce the report against the current main branch, then reply with the file and function most likely responsible, plus the test you would write first.

Folgendes sollte in dieser Reihenfolge geschehen. Recent Deliveries erfasst die issue_comment-Zustellung mit einer 2xx-Antwort. Der Dispatcher erfasst einen Lauf. Der Runner übernimmt ihn und beginnt mit Heartbeats. Der Executor öffnet den Checkout und arbeitet. Die Antwort erscheint als Kommentar im selben Issue-Thread. sudo -iu opentag opentag status zeigt den Lauf während seiner Ausführung an. Sie können ihn daher überwachen, statt den Ablauf zu erraten.

Setzen Sie approvalMode vor dem ersten echten Lauf auf ask. Im Modus ask pausiert der Lauf und wartet auf eine Person, bevor er Änderungen am Zustand vornimmt. Die Modi auto und autonomous sind ebenfalls vorhanden. Sie sind später sinnvoll, wenn Sie in einem Repository bereits einen Monat lang Transkripte geprüft haben.

Auf der Slack-Seite beginnt derselbe Lauf mit /bind owner/repo im Channel, gefolgt von einer Erwähnung. Der Bot antwortet außerdem auf /help, /status, /doctor, /stop und /unbind confirm. Beschränken Sie mit OPENTAG_SLACK_BINDING_ADMIN_USER_IDS, einer durch Kommas getrennten Liste von Slack-User-IDs, wer Bindings ändern darf. Ein Binding ordnet einen öffentlichen Channel einem Checkout auf Ihrem Server zu.

Triage ist ein guter erster Ablauf, weil dabei nur gelesen und nichts geschrieben wird. Außerdem lässt sich die Antwort einfach bewerten. Review ist der nächste Schritt. Dabei kommentiert der Agent einen Diff statt eines Issues: ein selbst gehosteter Pull-Request-Review-Agent verwendet dieselbe Architektur für Pull Requests. Wenn der Agent während seiner Arbeit auf Ihre eigenen Systeme zugreifen soll, sind MCP-Server auf einem VPS dafür zuständig.

Was passiert, wenn der Agent sich vor allen irrt?

Er wird sich irren. Entscheidend ist, welche Folgen das hat.

Eine falsche Antwort in einem öffentlichen Issue ist ein Kommentar unter einem Namen, den Ihr Team kennt. GitHub sendet ihn sofort nach der Veröffentlichung per E-Mail an alle Abonnenten. Wenn Sie den Kommentar löschen, wird die E-Mail nicht zurückgerufen. Dasselbe gilt für eine Slack-Benachrichtigung. Planen Sie damit, dass die Antwort öffentlich falsch sein kann, statt davon auszugehen, dass sie nur im Hintergrund richtig ist.

Vier Entscheidungen begrenzen den Schaden. Sie sind wichtiger als jeder Prompt, den Sie schreiben.

• Führen Sie den Agenten im ask-Modus aus. Dann macht der Agent einen Vorschlag, eine Person genehmigt ihn, und ein falscher Plan kostet nur einen Klick.
• Lassen Sie preparePullRequestBranch auf dem Standardwert false. Dann ist das schlimmste Ergebnis eines fehlerhaften Laufs ein falscher Kommentar und kein falscher Branch.
• Binden Sie zunächst ein Repository und einen Kanal. Der Runner lehnt jeden Lauf ab, dessen Projektziel außerhalb seiner lokalen Allowlist liegt. Ein nicht gebundenes Repository kann den Agenten daher nicht für sich einsetzen.
• Halten Sie das Commenting-Token vom Apply-Token getrennt. Wenn Sie den Schreibzugriff entziehen, bleibt die Triage dadurch verfügbar.

Slack bietet einen /stop-Befehl für einen Lauf, der in die falsche Richtung geht. Jeder Lauf hinterlässt außerdem einen Audit-Eintrag. Dieser enthält die Mention, die ihn gestartet hat, und die Aktionen des Agenten. Anhand dieses Eintrags können Sie anschließend nachvollziehen, wo der Fehler aufgetreten ist.

Die soziale Seite ist genauso wichtig wie die Konfiguration. Platzieren Sie den Bot in einem Kanal, in dem die Nutzer mit einer Maschine rechnen und wissen, dass sie sich irren kann. Eine selbstsicher vorgetragene falsche Antwort in einem Kanal mit vierzig Personen, die von einer menschlichen Prüfung ausgehen, verursacht mehr Aufwand, als die eingesparte Triage wert ist. Schreiben Sie in die Kanalbeschreibung, wer für den Bot verantwortlich ist und wer seine Ausgaben prüft.

Backups, Upgrades und Versionsbindung

Zwei Pfade enthalten alle Daten: /home/opentag/.config/opentag/config.json und /home/opentag/.local/state/opentag. Im ersten liegen Ihre Zugangsdaten, im zweiten die Ausführungshistorie und die Datenbankdatei. Sichern Sie beide mit dem Modus 600 und bewahren Sie die Sicherungen außerhalb des Servers auf. Bei einem Verlust müssen Sie Token und Bindings neu erstellen, nicht den Server neu aufbauen.

Upgrades bestehen aus einer Versionsaktualisierung und einem Neustart.

sudo npm install -g @opentag/cli@0.9.0
sudo -iu opentag opentag service stop
sudo -iu opentag opentag service start
sudo -iu opentag opentag doctor

Binden Sie die Version fest, statt @latest zu folgen. Diese Software führt mit einem aktiven Token einen Coding-Agent gegen Ihr Repository aus. Eine über Nacht veröffentlichte Version wäre daher eine ungeprüfte Änderung an diesem System. Die Security Policy stellt keine Backports bereit. Fehlerbehebungen erscheinen nur in der neuesten Version. Eine feste Version bedeutet deshalb, dass Sie das Changelog lesen und die Aktualisierung bewusst durchführen. Es bedeutet nicht, dass Sie dauerhaft bei v0.9.0 bleiben. Die Versionshistorie bis Juli 2026 zeigt mehrere Releases pro Monat. Das ist ein guter Grund, vor jeder Aktualisierung die Release Notes zu lesen.

FAQ

Benötige ich für OpenTag einen VPS, oder reicht ein Laptop?

Für Slack allein reicht ein Laptop, weil Socket Mode eine ausgehende WebSocket-Verbindung öffnet und keinen eingehenden Port benötigt. Bei GitHub ist das anders. Repository-Webhooks werden über eingehendes HTTP an eine URL zugestellt, die Sie einmal registrieren. Diese Adresse muss daher unverändert bleiben und antworten, während Sie schlafen. Die Adresse eines Tunnel-Hosts aus einem kostenlosen Konto ändert sich bei jedem Neustart. GitHub sendet weiterhin an die alte Adresse. Das wird im Tab „Recent Deliveries“ des Repositorys als fehlgeschlagene Zustellung angezeigt, während der Thread stumm bleibt. Ein VPS mit einem festen DNS-Namen und einem Zertifikat beseitigt beide Probleme.

Welche GitHub-Berechtigungen benötigt OpenTag?

Ein fein granularer persönlicher Zugriffstoken, beschränkt auf Only select repositories, mit Issues: Read and write und Pull requests: Read and write. Damit kann OpenTag eine Erwähnung lesen und im Thread antworten. Schreibzugriff auf den Code ist nicht erforderlich, außer Sie setzen preparePullRequestBranch auf true, damit OpenTag Branches pusht. Zusätzlich gibt es githubApplyToken, sodass der Token für Codeänderungen vom Token für Kommentare getrennt bleibt. Vermeiden Sie einen Token für alle Repositorys mit der Berechtigung „contents write“. Jeder, der in einem dieser Repositorys kommentieren kann, könnte damit einen Agenten steuern, der Commits erstellen kann.

Wie stoppe ich einen fehlerhaften Lauf?

Slack stellt dafür den Befehl /stop bereit. Auf dem Server zeigt opentag status, was gerade ausgeführt wird. opentag service stop stoppt den Daemon und beendet dadurch die gesamte Pipeline, nicht nur einen Lauf. Damit Sie keinen dieser Schritte benötigen, setzen Sie approvalMode auf ask. Dann pausieren Läufe, bevor sie Änderungen vornehmen, und warten auf eine Bestätigung. Lassen Sie preparePullRequestBranch auf false, damit ein fehlerhafter Lauf einen Kommentar statt eines Branches erzeugt.

Warum liefert mein Webhook 502, während der Thread stumm bleibt?

502 wird von nginx zurückgegeben, nicht von OpenTag. Der Status bedeutet, dass der Proxy den Listener nicht erreichen konnte. /var/log/nginx/error.log zeigt connect() failed (111: Connection refused) while connecting to upstream. Entweder wurde der Listener gestoppt, oder er verwendet einen anderen Port als in der Zeile proxy_pass angegeben. Führen Sie sudo ss -tlnp aus. Prüfen Sie, ob für GitHub auf 127.0.0.1:3050 und für Slack auf 127.0.0.1:3040 ein Listener aktiv ist. Führen Sie anschließend opentag doctor aus, um Bindings und Executoren zu prüfen.