Welche Daten verlassen die eigene covey-Installation?

Wer covey hinter der eigenen Firewall betreibt, bekommt früher oder später eine Frage gestellt, die keine Zusage beantwortet: Welche Verbindungen baut diese Software von sich aus nach außen auf, und was steht in den Paketen. Beantworten lässt sich das erst dort, wo die Software den Inhalt dieser Pakete zusammenstellt.

Auf Hacker News steht die Frage seit Jahren in derselben Form. Am 25. Oktober 2019 schrieb rswail in der Diskussion über GitLabs Telemetrie (Story 21343761): „Telemetry to any external service from inside our VPN is a definite no-go.“ In der Diskussion über die Telemetrie der GitHub-CLI (Story 47862331) hält yamajun93 am 23. April 2026 fest, was fehlt: „Would be good to see a clearer breakdown of whats collected and how it is anonymized.“ Ein anderer Kommentar dort nennt den harten Kern der Sache, nämlich dass dem Anwender jedes Mittel fehlt, eine solche Auskunft auf ihre Vollständigkeit zu prüfen.

Einmal am Tag gehen dreizehn Zahlenfelder hinaus

covey meldet fünf Minuten nach dem Start das erste Mal, danach alle 24 Stunden. Das Ziel steht in der Einstellung telemetry.url und lautet ab Werk https://covey.work/rueckkanal. Die Zahlen gehen an den Pfad /telemetrie, mit einem Zeitlimit von 20 Sekunden.

Was dort ankommt, lässt sich vollständig aufzählen. Es sind version und commit, die Anzahl der Organisationen, Menschen und Agenten sowie die Zahl der angestellten Agenten. Dazu kommen drei Zähler über die Aufgaben des letzten Tages, einer über die blockierten Aufgaben und die Zahl der angemeldeten Runner. Die beiden Felder runtimes und targets tragen Namen mit ihrer Anzahl. Dreizehn Felder also, jedes eine Zählung aus der Datenbank oder ein Versionsstring, zusammengestellt in der Funktion Zahlen in internal/telemetry/telemetry.go.

Dazu kommt eine Kennung: eine UUID, die sich die Installation beim ersten Mal selbst gibt und die in der Einstellung telemetry.id liegt. Sie trägt weder einen Namen noch eine Adresse. Ein Administrator kann sie nicht setzen: Der Schlüssel steht in der Liste der schreibgeschützten Einstellungen, damit zwei Installationen nicht als eine gezählt werden.

Einen zweiten Wert gibt es nur dort, wo jemand ihn hinterlegt hat. telemetry.key ist der optionale Schlüssel einer Installation, die das Projekt beim Namen kennt; er liegt versiegelt wie das SMTP-Passwort, und wo er gesetzt ist, steht er im selben Körper wie die Zahlen.

Was nie hinausgeht, hält ein Test fest

TestTelemetrieSchicktNurZahlen legt einen Agenten mit dem Slug geheimer-slug an und dazu eine Aufgabe mit dem Titel „Ein Titel, der niemanden etwas angeht“. Dann fängt er den Versand ab und durchsucht den Körper nach genau diesen Zeichenketten und nach der Adresse admin@test.local, und er schlägt fehl, sobald eine davon darin auftaucht.

Zwei Schalter prüft derselbe Test gleich mit. Nach telemetry.mode = off darf nichts mehr ankommen. Und COVEY_TELEMETRY=off aus der Umgebung muss über einer eingeschalteten Einstellung stehen.

Das ist die Antwort auf den Einwand aus der Diskussion vom April. Die Lizenz ist AGPL-3.0, die Zusammenstellung ist eine einzige Funktion, und der Quelltext nennt als Maßstab, dass ein Leser diese Liste in einer Minute prüfen kann.

Drei Schalter, und jeder schließt den Kanal ganz

Der erste ist telemetry.mode = off unter Plattform und Einstellungen. Der zweite ist eine leere telemetry.url: Die Prüfung der Einstellungen lässt den leeren Wert ausdrücklich zu und führt ihn als zweiten Weg. Der dritte ist COVEY_TELEMETRY=off in der Umgebung, und der wirkt schon vor dem ersten Start.

Gefragt wird an einer einzigen Stelle: TelemetryOn gibt Ziel und Erlaubnis zusammen zurück, und die Umgebung gewinnt dabei über die Einstellung.

Der Handel dahinter steht in der Doku, im Quelltext und in diesem Absatz: Telemetrie ist ab Werk an. Die Begründung lautet, eine Installation, die man erst fragen muss, melde nichts. Jede Antwort auf die Frage nach der laufenden Version wird damit zur Vermutung. In der Diskussion vom 22. April 2026 steht die Gegenposition genauso knapp. „This should be opt-in“, schreibt goosejuice.

Zwei Wege führen den Fehlerbericht eines Agenten hinaus, und nur einer hängt am Schalter

Der zweite Weg nach außen gehört covey Doctor. Findet dieser Agent einen Plattformfehler, den keine Konfiguration behebt, reicht er ihn als Issue ein, und zwar auf einem von zwei Wegen.

Liegt ein eigener Token als Secret der Organisation vor, etwa github_token oder gitlab_token, reicht die Steuerebene unter diesem Konto ein. Der Token bleibt dabei in der Steuerebene, und der Agent bekommt allein das Ergebnis des Aufrufs zurück. Dieser Weg fragt TelemetryOn nicht, sodass eine Organisation mit hinterlegtem Token auch nach telemetry.mode = off weiter Issues einreicht.

Fehlt ein solcher Token und zeigt das Ziel auf das Repository des Projekts, geht der Bericht über den Kanal zum Projekt, und dieser Weg fragt dieselbe Funktion wie die Zahlen. Dort liest ihn ein Mensch, bevor daraus ein Issue wird, sofern das Projekt die Installation nicht kennt. Bekannte gehen sofort durch, und in einen öffentlichen Tracker gelangt nichts ungelesen.

Wer die Schicht gar nicht will, stellt das Zielsystem unter „Quelltext dieser Plattform“ auf den Eintrag „gar nicht“, der als Bindestrich gespeichert wird.

Für beide Wege gelten zwei Eigenschaften. Das Ziel ist ein Stammdatum und kein Parameter des Aufrufs, sodass kein Lauf darüber entscheidet, wohin ein Bericht über diese Plattform geht. Und derselbe Bericht steht im Posteingang der Organisation, damit der Betreiber liest, was hinausging.

Damit liegt die Entscheidung beim Betreiber, und sie kostet ihn einen Blick in eine Funktion, eine Einstellung oder eine Umgebungsvariable.