Hot Tracking 035 | Installiert Postman KI-Plugins im Stillen?

Was passiert

Die Untersuchung durch den Autor fand über zwei Tage, vom 24. auf den 25. Oktober, statt. Alle Beweise stammen aus den lokalen Dateien und dem Quellcode des offenen Installers. Jeder Pfad kann selbst überprüft werden. Die Mechanismen werden nacheinander analysiert:

1. Die Logdateien von Postman zeigen eine automatische Installation an. In ~/Library/Application Support/Postman/logs/main.log gibt es am 24.10.2026 um 09:34Z eine Eintragung mit der Kategorie „auto-existing-upgrade“. Im Feld scriptResults steht claude-code:installed und codex:installed, während das Feld installer als script ausgewiesen wird.

2. Die globalen Konfigurationen von Codex wurden geändert. In ~/.codex/config.toml ist marketplace postman (der git-Source verweist auf postmanlabs/postman-plugin.git) eingefügt, und das Plugin-Eintragung enabled=true.

3. Der Umfang der Hook-Instructions ist zu breit. Im hooks/codex-hooks.json wurde die Hook SessionStart registriert (matcher überträgt startup, clear, compact). Dabei wird dem Modell eine Datei session-start-context.md ausgedruckt, die besagt: Vor der Beantwortung beliebiger nicht-trivialer API-Aufgaben (Design, Implementierung, Mocking, Testing, Monitoring, Dokumentation, Deployment von APIs oder Postman Flow) sollte die Fähigkeit postman:api-engineer geladen und befolgt werden. Dies ist viel weiter als der Bereich, in dem „der Benutzer explizit vorschreibt, Postman zu verwenden“.

4. Der Quellcode des Installers versucht, die Hook-Instanzen selbst zu vertrauen. In hooks.state werden trusted_hash und trusted_content_hash (zweifache SHA-256-Hashes) eingefügt. Nach dem Installieren ruft der Quellcode installer/src/hosts/codex.ts die Funktion approvePostmanHook() auf. codex-hooks.ts verwendet hooks/list, um die Hashes zu extrahieren und diese über config/batchWrite in das Vertrauensprotokoll einzutragen. Die Originalkommentare im Quellcode besagen: „Vertraut nur den aktuellen Hook von Postman nach dem Installieren.“ Der Autor bleibt hier zurückhaltend: Der Quellcode beweist „Versuche“, aber wer das Vertrauensprotokoll selbst erstellt hat, kann nicht durch die Dateien bewiesen werden.

5. Der remote MCP ist aktiviert, aber die Authentifizierung funktioniert nicht. mcp.codex.json verweist auf https://mcp.postman.com/mcp. Die Codex-Protokolle zeigen an, dass der MCP-Server beim Start fehlgeschlagen ist / Authentifizierung erforderlich ist. Der remote Service ist nicht verbunden, aber die Konfiguration wurde bereits eingetragen: Die Aktivierung geschah vor dem Wissen des Benutzers.

Sechstens: Claude Code wurde ebenfalls betroffen, und es wurde noch ein CLI hinzugefügt. Das ~/.claude/settings.json-File aktiviert postman@claude-plugins-official, und die installed_plugins.json-Datei verzeichnet die Version 2.0.1 sowie den Installationszeitpunkt 2026-10-24T09:34:02.610Z; im ~/.local/bin befindet sich das ausführbare File von Postman, und der mtime liegt innerhalb des Installationsfensters.

Versionen, die markiert sind: Postman Desktop 12.33.4, Codex Plugin 1.1.0, Claude Plugin 2.0.1. Der Quellcode ist auf der Revision 6c8e452 markiert und kann überprüft werden.

Der Autor hat nicht nur Kritik geäußert, sondern auch sechs klare Forderungen gestellt: Die schweren Probleme bezüglich Produktzustimmung und Sicherheitsgrenzen sollten als solche behandelt werden, anstatt als Dokumentationsprobleme; vor einer expliziten opt-in-Option sollten automatische Installationen von Agent-Plugins und CLI für bestehende Desktop-Benutzer eingestellt werden; die Selbstentscheidung bezüglich des Hook-Beliefens durch den Installator sollte entfernt werden, da das Beliefen muss vom Benutzer innerhalb des Agent-Hosts selbst entschieden werden; die Versionen, Feature-Flaggen und Zustimmungsprozesse hinter der auto-existing-upgrade-Funktion sollten offengelegt werden, um klar zu machen, welche Agenten und Dateien noch verändert werden können; eine vollständige Rückwärtsversetzung sollte bereitgestellt werden, die Agent-Konfigurationen, das Hook-Beliefen, den Marketplace, die Cache, die MCP-Verbindungen und das CLI umfasst, wobei die Löschung respektiert und keine Wiederinstallation erfolgt; die Startanweisungen sollten so eingeschränkt werden, dass der Benutzer explizit nach Postman fragt. Bis zum Zeitpunkt der Veröffentlichung wurden keine dieser sechs Forderungen erfüllt.

Eine stillschweigende Installation ist eine Produktentscheidung, kein Bug

Die Kritik an diesem Problem besteht aus einer vollständigen Zusammensetzung: Im Quellcode gibt es eine spezielle Funktion namens approvePostmanHook(), in den Logs gibt es eine spezielle Kategorie namens auto-existing-upgrade, und der Hash von hooks.state wurde tatsächlich erfolgreich gespeichert. Drei Beweise decken sich ab und deuten auf dasselbe mögliche Problem hin: Es handelt sich nicht um ein Versagen eines Abhängigkeitspakets, sondern um eine vom Entwicklungsprozess geplante Struktur, bei der die Zielgruppe aus den bestehenden Benutzern sind, die bereits Postman Desktop verwenden. Der Release/Feature-Flag- und Zustimmungsprozess hinter dieser Struktur ist nur dem Official bekannt. Die vierte Forderung des Autors ist daher die Offenlegung davon sowie die Frage, welche Agenten und Dateien mit diesem Mechanismus noch verändert werden können. Vom Veröffentlichungstermin am 25. Oktober bis zur Überprüfung am 4. November blieb das Problem offen, mit insgesamt 200 Reaktionen und keiner offiziellen Bewertung. Für ein Repository, das von einer offiziellen Organisation verwaltet wird, ist die zehn Tage des Schweigens selbst eine Geste.

Die sechs Forderungen des Autors sollten vollständig aufgeführt werden: Erstens, die schwerwiegenden Probleme bezüglich Produktzustimmung und Sicherheitsgrenzen als solche zu behandeln, anstatt sie als Dokumentationsprobleme zu betrachten; zweitens, die automatische Installation von Agent-Add-ons und CLI für bestehende Desktop-Benutzer vor einer expliziten Opt-in-Einstellung zu stoppen; drittens, die Selbstverständnisprüfung auf der Seite des Installators abzuschaffen, da die Zustimmung vom Benutzer am Agent-Host persönlich festgelegt werden muss; viertens, den Prozess der Zustimmung und die Auswirkungen hinter dem Auto-existing-upgrade offenzulegen; fünftens, einen vollständigen Rückstellpfad anzugeben (Agent-Konfigurationen, Selbstverständnisprüfung, Marketplace, Cache, MCP-Verbindung, CLI-Abdeckung), der nach dem Löschen nicht erneut installiert wird; sechstens, die Startanweisungen auf eine explizite Postman-Anfrage zu reduzieren.

Es gibt noch ein strukturelles Problem: Die Selbstverständnisprüfung funktioniert, weil die Zustimmungsschicht des Agent-Hosts selbst zu dünn ist. Auf der einen Seite gibt es Desktop-Software, die beliebige Konfigurationen im Benutzer-Verzeichnis vornehmen kann, auf der anderen Seite gibt es Hosts, deren Vertrauensdaten offline gefälscht werden können. Wenn Benutzer mit diesen beiden Optionen konfrontiert werden, erhalten sie nur das Ergebnis „eingesetzt“. Die Zustimmungsschicht des Agent-Ökosystems ist instabil; Postman ist nur der erste gefasste, die Details der Sicherheitslücken auf der Host-Seite finden Sie in den Kommentaren unten.

Die offizielle Aussage stimmt nicht

Schauen wir uns zunächst den Unterschied zwischen der Marketingseite und dem Verhalten auf dem Desktop. Auf der Downloadseite des offiziellen Postman-Webauftritts heißt es in der Plugin-Bereich: „Manuell das Plugin in Ihren Code-Proxy einfügen“, wobei zwei Befehle veranschaulicht werden (claude plugin marketplace add und install). Ein Nutzer hat nach dem Vergleich der Webseitenarchivate festgestellt, dass Postman die Beschreibung auf der Downloadseite geändert hat; was bestätigt werden kann, ist, dass sowohl die Seite vom 26.10.2026 als auch die aktuelle Seite vom 04.11. nur über die Marketingbereiche für manuelle Installationen informiert sind, ohne jegliche Informationen über automatische Installationen zu geben. Die offizielle Aussage steht im Widerspruch zum tatsächlichen Verhalten auf dem Desktop, was ein verifizierbares Faktum ist.

Schauen wir uns nun die strukturellen Daten des Problems an: In den 26 Kommentaren lautet author_association allein NONE – keine MEMBER, keine OWNER, keine COLLABORATOR haben sich geäußert; kein Label, kein assignee, kein milestone. Bis zum Zeitpunkt der Veröffentlichung hat Postman auf dieses Problem keine positive Antwort gegeben. Ein Nutzer berichtete, dass jemand auf Discord persönlich nachgefragt hat und das Gefühl hatte, „sie nehmen es nicht ernst“ (berichtete Aussage, nicht abzuschätzen). Der Autor hat auch nicht untätig gewartet: Er hat in den Subreddits r/postman_api, r/codex und r/ClaudeAI Beiträge veröffentlicht, aber es gab keine nennenswerten Reaktionen, bis am 3. November auf HN ein Beitrag veröffentlicht wurde.

Auch die Verbreitung der Informationen muss getrennt betrachtet werden: Der Titel des Beitrags auf HN lautet „Postman versucht, alle API-Daten zu teilen“, aber der Autor des Problems hat im Text klar die Grenzen gezogen: Dieser Bericht belegt keine gewünschten Integrationen oder Änderungen an den Anweisungen und plädiert nicht für die Übermittlung von Daten. Der Titel ist die Formulierung des Einreissers, die viel schärfer ist als die des Autors. Diejenigen, die den Beitrag weitergeleitet haben, sollten die beiden Teile getrennt betrachten.

Was sagen die Kommentare

Auf HN gab es fast 300 Diskussionen, wobei die positiven Meinungen in fünf Richtungen zusammengefasst wurden:

I. Die Migrationwelle ist die Hauptthema. Einige sagen, sie hätten vor Jahren Insomnia gewechselt und warten immer noch auf den Tag, an dem Insomnia Probleme bekommt; andere weisen darauf hin, dass Insomnia 8+ einen obligatorischen Cloud-Account erfordert, mit der offiziellen Begründung, dass dies es ermöglicht, Werbung an die Nutzer zu senden. Deshalb wechseln einige wieder zu Yaak; mehrere Nutzer haben Bruno gewechselt, einer davon behauptete, er habe die Arbeit verlassen, nachdem er von der Verkaufsabteilung von Postman belästigt wurde; in den Diskussionen gab es sogar einen, der eine Ersatzlösung namens librepost selbst entwickelte. Andere schlugen vor, das Team einfach auf curl und Shell-Skripts zurückzugreifen.

II. Die Theorie der Enshittification. Einen hochbewerteten Kommentar gibt folgende Logik: Je länger ein Tool Geld verdient, ohne die Produkte zu schädigen oder die Zeit der Nutzer zu verschwenden, desto langsamer wird die Verschlechterung. Doch sobald pathologische Gier einsetzt, wird es versuchen, die Nutzerbasis auszubeuten. Die stille automatische Installation wird gerade als Ergänzung zu dieser Entwicklung betrachtet.

III. Das Vertrauenmechanismus ist schwächer, als man denkt. Der Kommentator foma-agent hat zwei Hosts lokalisiert (Codex CLI 0.162.1, Claude Code 2.1.302, einmalige Konfigurationsordner): Die trusted_hash-Formel von Codex ist offen source, also der sha256-Wert des sort-key JSON-Teils des Hooks. Er berechnet den Hash offline mit Python und schreibt die contente von hooks.state in ein Texteditor, um beim nächsten Betrieb direkt einen Hook auszulösen, ohne dass jemand dabei beteiligt ist. Codex verfügt auch über das Flag —dangerously-bypass-hook-trust; die Vertrauensdaten werden nur auf den Hook-Ankündigungen (Befehlsfolgen, Ereignisse, Timeout) gespeichert, nicht auf dem Skriptinhalt. Nachdem die Daten erstellt wurden, wird der Skriptinhalt weiterhin ausgeführt. Der aktuelle Quellcode fügt den plugin Hooks einen Bundle-Hash hinzu, also einen zweiten Hash, aber die von den Nutzern angegebenen Hook-Skriptdateien bleiben allen Hashes entgegen. Claude Code verfügt sogar nicht über ein Aufzeichnungsmechanismus: Die Hooks in der settings-Datei treten sofort in Kraft, und die Hooks SessionStart und PreToolUse werden mit claude -p in einem nie vertrauten Ordner ausgelöst, was direkt eine Auslösung bewirkt (interaktive Sitzungen haben ein folder-trust-Fenster, -p-Modus hat keines). Die Bedeutung dieser Überprüfung ist: Die Selbstvertrauensprüfung von Postman ist keine schwierige Aufgabe, jeder Skript, der eine Konfigurationsdatei schreiben kann, kann sie durchführen.

IV. Motivielle Spekulationen und Seitenänderungen. Der Kommentator NuclEnergy behauptet, dass Postman später den Webinhalt geändert hat, um die Verantwortung zu vermeiden; nach Überprüfung lässt sich bestätigen, dass weder die Archivseite noch die aktuelle Seite von automatischer Installation sprechen, und der Pluginbereich hat immer nur über manuelle Installation berichtet. Was genau geändert wurde, kann nicht vollständig bestätigt werden. Er spekuliert auch, dass Postmans Absicht war, die von AI initiierten Netzwerkaufrufe zu überwachen und sich in die Allowlist einzutragen, was jedoch fehlschlug. Sowohl Codex als auch Claude Code haben Alarmen ausgelöst, der Skript ist sehr einfach geschrieben, und es war kurz davor, eine stille Installation durchzuführen (Spekulation, keine endgültige Schlussfolgerung). Er hat auch Screenshots eines mit Knöpfen versehenen Deinstallations-Hooks veröffentlicht und behauptet, Postmans Reinigungsskripte nicht zu vertrauen und GPT um Hilfe zu bitten.

Fünf, emotional aspect. Some people directly call Postman ein „Virus“, andere fragen, ob diese Praxis legal ist, wieder andere sagen, dass solche Risiken in einem Unternehmensumfeld nicht akzeptabel sind; man vergleicht es mit uTorrent: Jeder hat es installiert und behält es aus Gewohnheit bei; manche sagen, dass es innerhalb weniger Jahre von einer praktischen Tool-Alternative zu etwas geworden ist, das fast wie ein Virus funktioniert – seltsamerweise werden es immer noch viele Menschen verwenden. Einige rechnen nach: Der gesamte verkaufte Software-Set kostet nur den Preis für einen Prompt; manche verwenden einen amerikanischen Postweisheit, um es zu ironisieren: „Niemand regnet, niemand schneit, niemand stimmt zu.“ Die am häufigsten zitierten technischen Zusammenfassungen lauten: Ein weiteres Beispiel dafür, „was als Entwicklertool nicht getan werden sollte“, mit nur zwei Schlüsselwörtern: Transparenz und Genehmigung einholen.

Drei Dinge, die normale Nutzer tun können

1. Selbstüberprüfung der Konfiguration. Öffnen Sie cat ~/.codex/config.toml, um nach den Einträgen [marketplaces.postman], [plugins.”postman@postman”] und hooks.state zu suchen; öffnen Sie cat ~/.claude/settings.json und ~/.claude/plugins/installed_plugins.json, um Postman-Bezügliche Daten zu finden; schauen Sie sich kurz an, ob es in ~/.local/bin überflüssige Postman-Exe-Files gibt.

2. Nachdem Sie etwas gefunden haben, reinigen Sie es und überprüfen Sie es anschließend. Löschen Sie die entsprechenden Konfigurationseinträge und Dateien. In den Kommentaren glauben einige nicht an die offiziellen Deinstallationsskripte und wählen stattdessen eine manuelle Reinigung oder die Unterstützung durch KI; nach der Änderung starten Sie den Agent erneut, um sicherzustellen, dass die Hook-Funktionen nicht mehr ausgelöst werden.

3. Setzen Sie Grenzen. Bevor Sie irgendeine Plugins für Ihren Code-Proxy installieren, lesen Sie zuerst den Inhalt der SessionStart-Hook-Datei; wenn Sie eine Gruppe leiten, sollten Sie die Gefahr, dass „Desktop-Software die Konfiguration Ihres Agents verändert“, in die Risikobewertung der Anbieter einbeziehen. Der Hauptaktionär in diesem Fall ist Postman, und Schwachstellen im Mechanismus können von jeder Software auftreten, die in Ihre Verzeichnisstruktur eingreifen kann.

Schlussfolgerung

Hinweis auf die Grenzen: Dieser Artikel enthält keine voreingenommenen Aussagen oder Strafen. Der Kern der Anklage ist die Selbstbeschreibung des Beraters, aber Logpfade, Quellcode-Revisionen und strukturelle Daten von Problemen können überprüft werden; Motive und Angaben zur Änderung von Seiten stammen alle von Nutzern, der Artikel präsentiert die Informationen so, wie sie sind, ohne sie zu Fakten zu erheben. Nur drei Dinge können als sicher gelten: Probleme, die zehn Tage lang ohne Label bleiben, keine offiziellen Kommentare; keine automatischen Installationsangaben auf den beiden Versionen der Download-Seiten; der HN-Titel ist spitzer als die Worte des Autors des Problems. Für die gesamte Ökologie gilt, dass, egal wie die Offiziellen letztendlich reagieren, dieses Problem die Frage „Wem gehört das Vertrauen in die Desktop-Software in Bezug auf die Konfiguration des Agents?“ zur Sprache bringt.

Als nächste Punkte betrachten wir zwei Aspekte: Erstens, die offizielle Antwort von Postman. Sobald das Probleme mit Labels, Kommentaren oder Blogs auftritt, wird diese Rubrik in Version 2 aktualisiert; zweitens, ob Codex und Claude Code die Vertrauen in Hook-Funktionen im -p-Modus straffen werden – Foma-Agent hat Schwachstellen auf der Hostseite festgestellt, Postman ist nur der erste Nutzer, dem diese entdeckt wurden. Die 48-Stunden-Frist endet um 17:22Z am 5. November, und sobald etwas in einem dieser Punkte passiert, wird Version 2 aktualisiert.

Referenzquellen

• GitHub Issue: postmanlabs/postman-app-support#14370 (eingereicht am 2026-10-25 von indicava; Die Anklage basiert auf der eigenen Darstellung des Autors, der Quellcode ist in Revision 6c8e452 gespeichert und kann überprüft werden; Status: offen, 26 Kommentare, 200 Reaktionen, keine Labels, kein Assistent, entspricht dem API-Snapshot vom 11-04).
• Hacker News Story 50354960 (aufgenommen am 2026-11-03T17:22Z; Überprüfung mit mehr als 900▲, fast 300💬 – die Zahlen steigen weiterhin, der Text benötigt keine exakten Werte).
• Vergleich der Downloadseite der Postman-Website (Wayback-Archiv vom 2026-10-26 vs. aktuelle Seite vom 11-04; beide Versionen enthalten nur eine manuelle Installationsseite ohne Informationen zur automatischen Installation; der Nutzer „Änderung der Seite“ gibt an, dass die Darstellung nach Angaben des Autors erfolgt, ohne Strafverfolgung).
• Kommentare von Benutzer foma-agent zur lokalen Überprüfung des Vertrauensmechanismus zwischen Codex CLI 0.162.1 und Claude Code 2.1.302 (Kommentare wurden direkt getestet, in diesem Artikel wurde nicht wiederholt getestet).
• Verteilung der 26 Kommentare nach author_association (API-Überprüfung am 11-04: Alle NONE).

Unterschrift: Yongliang