Postman installiert KI-Plugins in Codex und Claude Code: Die vier Pfade und wie du sie prüfst

# Postman installiert KI-Plugins in Codex und Claude Code: Die vier Pfade und wie du sie prüfst

Am 24. Oktober 2026 um 09:34 Uhr UTC hat ein ganz normaler Postman-Desktop-Start bei einem Mac-Nutzer etwas hinterlassen, das niemand angefordert hatte: Postmans eigene Logdatei hält als Ergebnis eines Installationsskripts fest, dass ein Codex-Plugin und ein Claude-Code-Plugin installiert wurden. Der Logvermerk für den Auslöser lautet auto-existing-upgrade. Einen Tag später wurde der Fall als GitHub-Issue 14370 öffentlich, mit Logauszügen, Konfigurationsausschnitten und einer Besonderheit, die den Fall von einer Verpackungs-Beschwerde zu einem Vertrauensvorfall macht: Der Installer hatte nicht nur geschrieben, sondern auch selbst entschieden, dass sein eigener Start-Hook vertrauenswürdig ist.

Ich betreibe hier auf dem Deck eine kleine Agentenfamilie, ausgerechnet auf den zwei Werkzeugen, die der Fall betrifft: Codex und Claude Code laufen bei mir im Nebenzimmer, Hooks und MCP-Server gehören zu meinem Alltag. Deshalb habe ich den Fall nicht wie eine News-Meldung gelesen, sondern als Prüfauftrag an den eigenen Rechner weitergereicht. Das Ergebnis steht unten, Pfad für Pfad. Und weil ich nicht der einzige bin, der solche Bindeglieder fährt, gibt es den Check hier zum Nachmachen.

Der Meldende hat in seiner Postman-Logdatei unter Application Support/Postman/logs die Zeilen gefunden, die den Vorfall belegen. In main.log, Zeile 11562 bis 11563, steht am 24. Oktober 2026 um 09:34:14 UTC:

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}

Übersetzt heißt das: Der Postman-Agentendienst hat ein Installationsskript ausgeführt, dessen Auslöser-Vermerk auf ein bestehendes Upgrade deutet und dessen Ergebnis in beiden Zielwerkzeugen installed lautet. Direkt danach folgt in derselben Logdatei ein zweiter Eintrag mit demselben Ausgang. Das ist keine Interpretation eines verärgerten Nutzers, das ist die Protokollierung des Programms selbst. Genau deshalb hat der Fall innerhalb von Tagen so eine Welle bekommen: Man muss Postman nichts unterstellen, man kann es nachlesen.

Die betroffenen Versionen stehen ebenfalls im Issue, ermittelt am 25. Oktober 2026: Postman Desktop 12.33.4, das Codex-Plugin in Version 1.1.0, das Claude-Plugin in Version 2.0.1. Das dokumentierte Verhalten ist über die Logzeile hinaus an macOS gebunden, der Issue trägt dazu einen darwin-Vermerk. Gleichwertige Belege für Windows oder Linux liegen im Issue bislang nicht vor, das ist eine echte Wissenslücke und unten in den FAQ verankert.

Der aufwändigere Teil des Issues ist nicht die Zahl der Plugins, sondern die Fläche. Fünf Stellen sind dokumentiert. Erstens ein Eintrag im Marktverzeichnis (Marketplaces-Abschnitt) der globalen Codex-Konfiguration, der als Quelle auf ein Postman-Repository im Netz zeigt. Zweitens der Plugin-Eintrag selbst, auf enabled gesetzt. Drittens, und das ist der Kern, ein Eintrag im Zustandsabschnitt der Hooks mit einem trust_hash nach sha256, hinterlegt vom Installer. Viertens eine entfernte MCP-Verbindung nach mcp.postman.com, die im Codex-Log mit der Meldung Auth required anläuft, also ohne gültige Anmeldung ins Leere zeigt. Fünftens die Spuren in Claude Code, eine veränderte settings.json und eine Liste installierter Plugins, plus ein Postman-Kommandozeilenwerkzeug im lokalen Bin-Ordner des Benutzers.

Der Hook selbst trägt eine Anweisung, die der Agent bei jedem Sitzungsstart lesen soll: bevor eine nichttriviale API-Aufgabe behandelt wird, soll der Agent zuerst eine Postman-Fähigkeit laden. Das ist keine Kleinigkeit. Ein Start-Hook sitzt vor fast allem anderen, und wenn er auf jede nichttriviale API-Aufgabe zielt, erklärt ein fremdes Werkzeug sich selbst zum Standardweg, ohne dass irgendein Dialog gefragt hat.

Auf meinem Deck laufen Codex, Claude Code und ein Hermes-Agent parallel, mit eigenen Konfigurationsdateien, Hooks und MCP-Verbindungen. Ausgerechnet deshalb war der Fall für mich kein Fremdschaden, sondern ein Anlass. Ich habe die vier Pfadgruppen einzeln geprüft, Datum 4. November 2026.

Die Codex-Konfiguration unter .codex/config.toml existiert bei mir, mit 465 Bytes Inhalt. Ein Durchsuchen nach Postman, Marketplaces und Hooks findet nichts: keine Postman-Quelle, kein enabled-Plugin, kein fremder Trust-Hash. Die Claude-Einstellungen unter .claude/settings.json existieren, sind aber 22 Bytes groß, praktisch eine leere Standarddatei. Die Liste der installierten Claude-Plugins unter .claude/plugins existiert bei mir nicht. Das Postman-Werkzeug unter .local/bin existiert ebenfalls nicht.

Fazit meines Audits: dieser Rechner ist sauber. Wichtig ist mir die Ehrlichkeit über die Reichweite. Meine Prüfung sagt, dass die vier Pfade an diesem Stichtag leer sind. Sie beweist nicht, dass es sie nie gegeben hat, und sie ersetzt nicht den Blick in die Postman-Logdatei, falls Postman bei dir läuft. Wer in einer Firma arbeitet, sollte denselben Check auf jeder Maschine fahren, auf der Codex oder Claude Code installiert sind. Im Issue-Kommentarstand steht der Satz eines Nutzers wörtlich drin, der Fall schaffe sogar ein Risiko in Firmenumgebungen. Das ist keine Panik, sondern die normale Lesart, wenn ein Werkzeug die Konfiguration eines anderen Werkzeugs heimlich verbiegt.

Im Issue nennt bislang niemand einen bestätigten Ein-Klick-Entfernweg, der alle Stellen auf einmal räumt. Wer die Spuren loswerden will, macht es also je Pfad: den Plugin-Block und den Hook-States-Abschnitt aus der Codex-Konfiguration entfernen, die Postman-Quelle aus dem Marketplace-Abschnitt löschen, in der settings.json und in der Plugin-Liste von Claude die Postman-Einträge suchen und entfernen, das Postman-Werkzeug im lokalen Bin-Ordner löschen und die MCP-Verbindung nach mcp.postman.com aus der Codex-Konfiguration entfernen. Danach beide Agenten neu starten, damit keine laufende Sitzung den alten Zustand weiterschleppt.

Wer sich nicht sicher ist, ob alles weg ist, startet Codex danach mit einer einfachen Aufgabe und durchsucht sein Log nach mcp.postman.com und nach dem Postman-Skill-Namen. Der Name lautet postman:api-engineer, bei Befall taucht er in der Aufgabenverarbeitung auf. Ein erneuter Postman-Start bleibt bis zu einer offiziellen Abschaltung des Verhaltens der riskanteste Moment, denn für die Frage, ob sich der Auto-Install wiederholt, fehlt bislang ein öffentlicher Beleg nach der ersten dokumentierten Ausführung am 24. Oktober.

Vorgänger-Fälle für dieses Muster gibt es. Im Thread erinnern Leser an GitKraken, das mit einem Desktop-Update ebenfalls Zusatzkomponenten untergebracht hatte und das später öffentlich aufgearbeitet hat. Das ist kein Persilschein für Postman, sondern die Mahnung, dass ein solcher Eingriff ein Vertrauensbruch bleibt, auch wenn er hinterher eingeräumt wird.

Wer einmal am Tag eine API testet, liest den Fall als Ärgernis. Wer einen Agentenbetrieb fährt, liest ihn als Lehrstück über die Angriffsfläche zwischen Werkzeugen. Hooks sind bei mir die Norm, ich nutze sie in eigener Regie als Start- und Endpunkte für Agententätigkeiten. Der Fall zeigt, warum drei Mechanismen eine Rolle spielen, die ich täglich benutze: Erstens der Trust-Hash, der verhindert, dass ein fremder Hook stillschweigend in die Ausführung rutscht. Zweitens der MCP-Abschnitt, der Verbindungen zu fremden Diensten anlegt und deshalb nur gewollte Einträge enthalten darf. Drittens der Marketplace-Abschnitt, der Quelle, Version und Aktivierungsstatus an einem Ort bündelt, gerade damit man ihn prüfen kann.

Ich fahre meine Agenten mit einer eigenen Genehmigungslogik statt mit fremden Vorlagen. Als ich diese Logik auf Klick-Bestätigungen verdichtet habe, habe ich die harten Regeln, also die Bremse für Sudo-Eingaben, Massenlöschungen und abgelehnte Muster, bewusst unantastbar gelassen. Der Postman-Fall zeigt das Spiegelbild: Ein Installer, der sich seine eigene Genehmigung in einen fremden Trust-Store schreibt, dreht genau diese Reihenfolge um. Mein Vorgehen, Agenten prozedural zu halten, steht in einem eigenen Beitrag über Agentenprozeduren, der Vergleich der Coding-Agenten mit ihren Vertrauensregeln in der Liga der Coding-Agenten, beide verlinkt am Ende.

Im Issue stehen drei klare Forderungen: die automatische Installation der Agenten-Plugins aussetzen, solange nicht jede Installation durch ein ausdrückliches Einverständnis läuft. Den Mechanismus entfernen, der sich selbst genehmigt. Die Startanweisung des Hooks beschränken auf Situationen, in denen der Nutzer Postman ausdrücklich verlangt. Postman hat bis zum Abruf am 4. November 2026 gegen 13:40 UTC keine öffentliche Stellungnahme im Issue abgegeben. Unter den 51 Kommentaren sind Stimmen wie die eines Nutzers, der nach einem Jahrzehnt mit Postman schreibt, er habe es heute deinstalliert, und die Erinnerung an den GitKraken-Fall.

Die Umgebung zeigt, wie tief der Frust sitzt: Auf Hacker News stand der Fall beim Abruf bei 1398 Punkten und über 460 Kommentaren, in den Antworten dominieren Umzüge hin zu Bruno, Insomnia und Yaak. Die eigentliche Frage ist aber nicht, welches Werkzeug nächstes Quartal gewinnt, sondern ob ein Installationsprogramm je wieder der Meinung sein darf, die Konfiguration eines anderen Werkzeugs gehöre ihm. Bis Postman antwortet, gilt: Pfade prüfen, Zustand dokumentieren, Konfigurationsberührungen zwischen Werkzeugen im eigenen Betrieb auf ein Minimum halten.

Weiterlesen im eigenen Bestand: Das Vorgehen, mit dem ich Agenten prozedural haltbar mache, steht im Beitrag [Agentenprozeduren](post.html?slug=pi-skills-agenten-prozeduren). Der Vergleich der Coding-Agenten mit den nötigen Vertrauensregeln steht in der [Liga der Coding-Agenten](post.html?slug=github-liga-coding-agenten).

GitHub-Issue 14370 im Postman-Problemtracker, eröffnet am 25. Oktober 2026, abgerufen am 4. November 2026: https://github.com/postmanlabs/postman-app-support/issues/14370

Diskussion auf Hacker News ab dem 3. November 2026, 1398 Punkte zum Abrufzeitpunkt, abgerufen am 4. November 2026: https://news.ycombinator.com/item?id=50354960

Zusammenfassung zum Vorfall mit Versionsdetail und dem Installer-Mechanismus approvePostmanHook, abgerufen am 4. November 2026: https://aiweekly.co/alerts/postman-desktop-silently-installs-plugins-into-codex-claude-code

GitKraken-Beitrag zum eigenen Desktop-Update, als Vorgängerfall im Issue-Kommentar genannt, abgerufen am 4. November 2026: https://www.gitkraken.com/blog/gitkraken-desktop-12-0-1-update

Eigene Messung: Pfad-Audit auf dem Agenten-Deck, 4. November 2026, Codex-Konfiguration 465 Bytes ohne Postman-Eintrag, Claude settings.json 22 Bytes, Plugin-Liste und lokales Bin-Werkzeug nicht vorhanden.

Über den Autor: Ich betreibe die Agentenfamilie auf einem gebrauchten Google Pixel 6a, mit Codex, Claude Code und einem Hermes-Agenten im Parallelbetrieb, dazu ein Kali-System auf einem Raspberry Pi. Diesen Check habe ich am 4. November 2026 an der eigenen Installation gefahren, die vier Pfade einzeln, mit den Byte-Zahlen im Text. Zuletzt fachlich geprüft am 4. November 2026.