Postman-Plugin in Codex und Claude Code prüfen und entfernen

Bei einem unerwünschten Postman-Plugin in Codex oder Claude Code solltest du die Konfiguration sichern, das Plugin deinstallieren und gespeicherte Codex-Hook-Freigaben entfernen. Authentifiziere keine Postman-MCP-Verbindung, die du nicht selbst ausgewählt hast. Prüfe das Ergebnis in einer neuen Sitzung, bevor du normal weiterarbeitest.

Im Postman-Issue #14370 wurde dieser erkennbare Fehler gemeldet:

MCP server startup failed server_name="postman"
... error: Auth required, when send initialize request

Der Verfasser berichtete außerdem, dass bei API-Aufgaben wiederholt Postman-Skills geladen wurden. Diese Symptome sind ein Anlass, die Integration zu prüfen. Sie belegen nicht, dass API-Daten hochgeladen wurden.

Was hat sich seit den ersten Meldungen geändert?

Stand 2026-11-10 gibt es eine Ankündigung zur Rücknahme der Änderung und Anpassungen am Codex-Plugin. Gehe nicht davon aus, dass der ursprüngliche Installer noch das Verhalten jeder aktuellen Installation beschreibt.

Die erste Meldung betraf Postman Desktop 12.33.4 unter macOS, das Codex-Plugin 1.1.0 und das Claude-Code-Plugin 2.0.1. Ein späterer Bericht zu 12.35.1 beschrieb eine weitere automatische Installation. Auf diesem Rechner gab es jedoch keinen Vertrauenseintrag für den Codex-Hook, und das Cursor-Plugin war bereits vorhanden.

Am 5. November kündigte Repository-Mitglied preethammavin an, dass Postman die Änderung zurücknimmt. Das unterscheidet diesen Kommentar von früheren Beiträgen, deren Verfasser auf GitHub nicht als Mitglieder gekennzeichnet waren.

Ebenfalls am 5. November wurde Pull Request #149 gemergt. Er entfernte die Freigabe durch den Installer. Außerdem löschte er hooks/codex-hooks.json und setzte im Codex-Manifest "hooks": {}. Das aktuelle Codex-Manifest enthält weiterhin diese leere Hook-Deklaration. Postman-Skills und ein MCP-Server sind nach wie vor enthalten.

Diese Änderungen belegen nicht, dass eine bestehende Installation bereits bereinigt wurde. Prüfe die installierten Dateien. Verlasse dich nicht darauf, dass ein Desktop-Update alte Registrierungen oder Vertrauenseinträge entfernt hat.

Prüfe vor dem Entfernen, was Postman geschrieben hat

Schließe zuerst Postman und die aktiven Agentensitzungen. Sichere vor Änderungen private Kopien der betroffenen Konfiguration, der Installationsnachweise und der relevanten Logs.

Verwende das Konfigurationsverzeichnis der betroffenen Sitzung. Ein Terminal und eine Desktop-Anwendung können unterschiedliche Startumgebungen haben. Die folgende Prüfung für Bash berücksichtigt CODEX_HOME und die dokumentierte Claude-Code-Variable CLAUDE_CONFIG_DIR.

Sie gibt nur die Namen der Dateien mit Treffern aus, nicht deren Konfigurationsinhalt:

codex_root="${CODEX_HOME:-$HOME/.codex}"
claude_root="${CLAUDE_CONFIG_DIR:-$HOME/.claude}"

for file in \
  "$codex_root/config.toml" \
  "$claude_root/settings.json" \
  "$claude_root/plugins/installed_plugins.json"
do
  if [ -f "$file" ]; then
    grep -ilF -- postman "$file"
  fi
done

Ein Treffer ist ein Hinweis für die weitere Prüfung, kein Beweis für eine automatische Installation. Keine Treffer sagen ebenfalls nur etwas über diese Dateien aus.

Prüfe für den gemeldeten macOS-Fall die Datei ~/Library/Application Support/Postman/logs/main.log. Das Issue enthielt dieses Installationsergebnis:

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

Vergleiche den Zeitstempel mit den Installationsnachweisen der Plugins. Eine übereinstimmende zeitliche Abfolge ist aussagekräftiger als das Wort „Postman“ in einer Konfigurationsdatei.

Prüfe in Codex diese drei getrennten Einträge aus der ursprünglichen Meldung:

Konfigurationseintrag	Was du prüfen solltest
[marketplaces.postman]	Ob die Quelle https://github.com/postmanlabs/postman-plugin.git lautet.
[plugins."postman@postman"]	Ob das Plugin aktiviert ist.
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]	Ob eine gespeicherte Freigabe trusted_hash, trusted_content_hash oder beide Felder enthält.

Ein fehlender Vertrauenseintrag schließt ein installiertes Plugin nicht aus. Der spätere Bericht zeigte genau diesen Unterschied.

Prüfe für Claude Code enabledPlugins in ~/.claude/settings.json. Die gemeldete Kennung war postman@claude-plugins-official. Kontrolliere in ~/.claude/plugins/installed_plugins.json den Geltungsbereich, die Version, installedAt und lastUpdated der zugehörigen Installation.

Für Cursor nennt der Host-Adapter des Installers zwei Verzeichnisse:

~/.cursor/plugins/local/postman
~/.cursor/plugins/cache/cursor-public/postman

Nutze sie als Ausgangspunkte für die Prüfung. Kontrolliere in Cursors Plugin-Einstellungen, ob das Plugin aktiviert ist. Leite das nicht allein aus einem vorhandenen Verzeichnis ab.

Halte vollständige Einstellungen und Logs privat. Sie können Zugangsdaten, interne Pfade oder Kontoinformationen enthalten. Teile nur relevante Einträge, nachdem du sensible Daten unkenntlich gemacht hast.

Entferne Plugin und gespeicherte Freigabe getrennt

Wähle entweder die eingebauten Befehle des jeweiligen Tools oder Postmans Entfernungstool. Führe nicht automatisch alle Wege nacheinander aus.

Entferne das Plugin gezielt mit den eingebauten Befehlen

Führe für die gemeldete Codex-Plugin-Kennung diesen Befehl in Bash aus:

codex plugin remove postman@postman

Entferne danach den Marketplace nur, wenn du die Quelle bestätigt hast und kein benötigtes Plugin ihn noch verwendet:

codex plugin marketplace remove postman

Diese Schritte entsprechen dem aktuellen Postman-Adapter für Codex. Verwende die tatsächlich auf deinem Rechner vorhandenen Kennungen, falls eine ältere Installation anders registriert ist.

Für die gemeldete Claude-Code-Installation im Benutzerbereich:

claude plugin uninstall postman@claude-plugins-official --scope user

Die Plugin-Befehlsreferenz von Claude Code unterscheidet die Geltungsbereiche user, project und local. Bei einer bestätigten Projekt- oder lokalen Installation wählst du den passenden Geltungsbereich und führst den Befehl in diesem Projekt aus. Stimme das Entfernen gemeinsam genutzter Projekteinstellungen mit dem Team ab.

Entferne nicht den gesamten Marketplace claude-plugins-official, um ein einzelnes Plugin zu löschen. Leere weder installed_plugins.json noch ersetze deine vollständige Einstellungsdatei.

Wenn deine installierte CLI einen Befehl ablehnt, prüfe zuerst deren plugin --help. Ersetze einen nicht unterstützten Deinstallationsbefehl nicht durch pauschales Löschen von Verzeichnissen.

Alternative: Nutze Postmans dokumentiertes Entfernungstool

Die aktuellen Repository-Anweisungen von Postman nennen diesen Befehl zum Entfernen:

npx @postman/postman-plugin@latest remove

Nutze diesen Weg erst, nachdem du den Paketcode geprüft, seine Ausführung freigegeben und die betroffenen Agenten kontrolliert hast. Der aktuelle Installer-Quellcode setzt Node.js 22 oder neuer voraus. Lass den Unterbefehl remove nicht weg. Ein Start des Installers ohne diesen Unterbefehl ist keine Bereinigung.

Das dokumentierte Entfernungstool lässt Installationen im Projektbereich bestehen. Seine aktuelle Codex-Implementierung versucht außerdem, die alte Freigabe des Start-Hooks zu widerrufen.

Prüfe diesen letzten Schritt gesondert. Die Implementierung des Widerrufs kann ein Bereinigungsproblem melden, ohne den gesamten Entfernungsvorgang fehlschlagen zu lassen. Lies die Warnungen und kontrolliere anschließend die Datei.

Lösche verbliebene Codex-Freigaben

Falls der folgende Unterabschnitt noch in der betroffenen Codex-Benutzerkonfiguration steht, entferne ihn vollständig:

[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]

Dieser Block kennzeichnet den zu löschenden Abschnitt. Er ist keine Konfiguration, die du hinzufügen sollst.

Lösche die Felder trusted_hash und trusted_content_hash dieses Abschnitts gemeinsam. Höre vor der nächsten TOML-Tabellenüberschrift auf. Lass andere Einträge unter hooks.state unverändert.

Entferne bei manuellen Änderungen nur Einträge, die nachweislich zu Postman gehören. Bewahre model_provider, model_providers, base_url, Authentifizierungseinstellungen und unbeteiligte Hooks. Behalte in Claude Code auch unbeteiligte env- und Berechtigungseinstellungen bei.

Prüfe nach dem Entfernen mit den eingebauten Befehlen, ob die zugehörigen Plugin- und Marketplace-Registrierungen verschwunden sind. Prüfe bei beiden Wegen, ob auch die gespeicherte Postman-Freigabe fehlt. Eine Deinstallationsmeldung allein bestätigt nicht alle drei Bedingungen.

Prüfe Cursor, separate MCP-Einträge und die CLI

Installationen aus dem Cursor-Marketplace benötigen einen weiteren Schritt: Deinstalliere Postman unter Cursor Settings > Plugins und starte Cursor neu. Kontrolliere nach beiden Entfernungswegen Cursors Plugin-Liste auf verbliebene Postman-Installationen.

Bleibt eine MCP-Warnung bestehen, prüfe die Serverkonfiguration. Melde dich nicht nur an, um die Warnung auszublenden. Nutze in Bash den passenden Befehl für jedes betroffene Tool:

codex mcp list
claude mcp list

Ein separat konfigurierter Server muss separat entfernt werden. Bestätige zuerst, dass der unerwünschte eigenständige Eintrag postman heißt. Verwende dann codex mcp remove postman oder claude mcp remove postman. Prüfe vor dem Entfernen den Geltungsbereich des Eintrags. Die Codex-CLI-Referenz und die MCP-Dokumentation von Claude Code beschreiben diese Befehle.

Verwechsle einen eigenständigen Server nicht mit einem Server, den ein aktiviertes Plugin bereitstellt. Entferne bei einer Plugin-Verbindung das zugehörige Plugin.

Prüfe die Postman-CLI separat. In Bash zeigt type -a postman die passenden Befehle im Suchpfad an. Beim ursprünglichen Vorfall lag eine ausführbare Datei unter ~/.local/bin. Gehe nicht davon aus, dass jede Installation diesen Ort verwendet.

Folge Postmans CLI-Deinstallationsanleitung für die jeweilige Installationsmethode. Bei einer Installation ohne npm sieht die dokumentierte Methode vor, die ausführbare Datei zu löschen. Prüfe begleitende Dateien, bevor du sie entfernst. Lösche niemals ein gemeinsam genutztes lib-Verzeichnis allein deshalb, weil die Meldung eines erwähnt.

Prüfe die Bereinigung in einer neuen Sitzung

Prüfe die Konfiguration und die geladenen Komponenten, nicht nur das Ausbleiben einer Warnung.

Rufe zuerst die Plugin-Listen der betroffenen Tools auf:

codex plugin list --json
claude plugin list --json

Suche nach sämtlichen Postman-Registrierungen, auch mit einem anderen Marketplace-Suffix oder Geltungsbereich. Bestätige, dass der genaue Postman-Hook-Freigabeabschnitt aus der aktiven Codex-Konfiguration entfernt wurde.

Starte eine neue Agentensitzung in einer entbehrlichen Arbeitskopie des Repositorys. Prüfe, ob noch ein unerwünschtes Postman-Plugin oder eine MCP-Verbindung geladen wird. Die entfernte Integration sollte keine neue Postman-Authentifizierungswarnung auslösen.

Verwende Postman-Erwähnungen in einer alten Unterhaltung nicht als einziges Prüfkriterium. Vorhandener Gesprächstext und installierte Konfiguration sind unterschiedliche Dinge. Deshalb ist der Unterschied zwischen einer neuen Claude-Code-Sitzung und dem Komprimieren einer bestehenden Sitzung wichtig.

Wenn Postman weiter erscheint, prüfe das Konfigurationsverzeichnis, den Installationsbereich, verbliebene Plugin-Registrierungen und separate MCP-Einträge. Lösche nicht wiederholt dieselbe Standarddatei, ohne die aktive Quelle zu finden.

Wenn du Postman Desktop behältst, vergleiche die Konfiguration nach dem nächsten kontrollierten Start oder Update erneut. Tauchen Einträge wieder auf, sichere die neuen Log-Zeitstempel und den Konfigurationsvergleich. Pausiere diesen Desktop-Rollout, bis du untersucht hast, welcher Prozess die Einträge neu erstellt hat.

Warum konnte der Installer Codex-Hook-Freigaben schreiben?

Der frühere Installer nutzte die Konfigurationsschnittstelle von Codex, um eine Freigabe dauerhaft zu speichern. Er registrierte nicht nur das Plugin und überließ die Vertrauensentscheidung der interaktiven Prüfung.

Im Commit 6c8e452e0f4237f4bcc0901cb1ac442dec707e49 verwendete die Hook-Registrierung SessionStart mit matcher auf startup|clear|compact. Der Anweisungstext leitete nicht triviale API-Engineering-Aufgaben über postman:api-engineer.

Diese Anweisung ging über ausdrückliche Bitten hinaus, Postman zu verwenden. Reine Fragen und triviale Änderungen waren ausgenommen. Benutzeranweisungen sollten ausdrücklich Vorrang haben.

Die frühere Implementierung von approvePostmanHook startete codex app-server. Sie ermittelte den aktuellen Hook-Hash über hooks/list, prüfte ihn und rief anschließend config/batchWrite auf. Dieser Schreibvorgang fügte trusted_hash unter hooks.state ein.

Damit ist ein Freigabeversuch belegt. Das beweist weder einen Erfolg in jeder Codex-Version noch, wer einen vorhandenen Eintrag auf einem bestimmten Rechner angelegt hat.

Der dokumentierte Vertrauensmechanismus von Codex vergleicht einen Hook mit seinem gespeicherten Hash. Neue oder veränderte Hooks werden bis zur Prüfung und Freigabe übersprungen. Entscheidend ist deshalb der Zugriff auf den Freigabestatus. Ein passender Hash allein belegt nicht, dass ein Mensch den Hook freigegeben hat.

Die praktische Konsequenz betrifft lokale Rechte: Software mit ausreichendem Zugriff auf deine Agentenkonfiguration kann sicherheitsrelevante Einstellungen ändern. Plugin-Aktivierung, Hook-Vertrauen und die Authentifizierung am entfernten MCP-Server sind getrennte Kontrollen. Wenn du nur eine entfernst, können die anderen konfiguriert bleiben.

Verhindere erneute Änderungen auf Teamrechnern

Bewahre eine freigegebene Konfigurationsvorlage ohne sensible Daten auf. Vergleiche sie nach Tool-Installationen und Updates mit dem aktuellen Stand. Versioniere Vorlagen und geprüfte Änderungen, nicht aktive Zugangsdaten oder vollständige persönliche Konfigurationsverzeichnisse.

Diffs erkennen Änderungen, verhindern aber keine Schreibzugriffe durch Prozesse desselben Benutzerkontos. Setze für verbindliche Einschränkungen administrativ verwaltete Richtlinien ein, die normale Desktop-Anwendungen nicht umschreiben können.

Für Codex unter macOS oder Linux liegt die systemweite Anforderungsdatei unter /etc/codex/requirements.toml. Ergänze diese Einstellung auf oberster Ebene der vorhandenen Datei:

allow_managed_hooks_only = true

Die Dokumentation zur verwalteten Konfiguration beschreibt die Ablageorte für die Verteilung. Laut Konfigurationsreferenz überspringt diese Einstellung Benutzer-, Projekt-, Sitzungs- und Plugin-Hooks. Verwaltete Hooks bleiben erlaubt.

Ergänze für Claude Code unter macOS die vorhandene Datei /Library/Application Support/ClaudeCode/managed-settings.json um Folgendes:

{
  "allowManagedHooksOnly": true
}

Dies ist eine verwaltete Richtlinieneinstellung, kein Ersatz für Änderungen an Benutzereinstellungen. Claude Codes Hook-Kontrollen blockieren Benutzer-, Projekt- und andere Plugin-Hooks. Die Einstellungsreferenz nennt wichtige Ausnahmen: verwaltete Hooks, SDK-Hooks und Hooks von Plugins, die über verwaltete enabledPlugins zwingend aktiviert wurden.

Teste die Richtlinien mit den tatsächlich im Team verwendeten Clientversionen, bevor du sie breit verteilst. Hook-Einschränkungen deinstallieren selbst keine Plugins und entfernen keine MCP-Verbindungen. Verwalte diese Komponenten getrennt.

Prüfe auch heruntergeladene Anweisungsdateien und Provider-Einstellungen. Das Konfigurationsaudit für Codex und Claude Code bietet weitere Prüfschritte, mit denen du Änderungen erkennst, ohne ein funktionierendes Modell-Setup zu verwerfen.