Plugin Postman dans Codex et Claude Code : vérifier et supprimer

Si un plugin Postman indésirable apparaît dans Codex ou Claude Code, sauvegardez la configuration, désinstallez le plugin et supprimez son approbation de hook Codex. N’authentifiez pas une connexion MCP Postman que vous n’avez pas choisie. Vérifiez le résultat dans une nouvelle session avant de reprendre votre travail habituel.

Le symptôme décrit dans le signalement Postman #14370 était le suivant :

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

L’auteur décrivait aussi le chargement répété de compétences Postman pendant des tâches liées aux API. Ces symptômes justifient de vérifier l’intégration. Ils ne prouvent pas que des données d’API ont été envoyées.

Qu’est-ce qui a changé depuis les premiers signalements ?

Au 2026-11-10, Postman avait annoncé l’annulation du changement et modifié le plugin Codex. Ne supposez pas que le comportement de l’ancien installateur décrit encore toutes les installations actuelles.

Le premier signalement concernait Postman pour ordinateur 12.33.4 sur macOS, avec le plugin Codex 1.1.0 et le plugin Claude Code 2.0.1. Un signalement ultérieur concernant 12.35.1 décrivait une autre installation automatique. Toutefois, cet ordinateur n’avait aucun enregistrement d’approbation du hook Codex, et son plugin Cursor était déjà installé.

Le 5 novembre, preethammavin, membre du dépôt, a annoncé que Postman annulait ce changement. Ce commentaire se distingue des précédents, dont les auteurs n’étaient pas identifiés comme membres sur GitHub.

Également fusionnée le 5 novembre, la pull request #149 a supprimé l’approbation effectuée par l’installateur. Elle a aussi supprimé hooks/codex-hooks.json et défini "hooks": {} dans le manifeste Codex. Le manifeste Codex actuel conserve cette déclaration vide de hooks. Il inclut toujours les compétences Postman et un serveur MCP.

Ces changements ne prouvent pas qu’une installation existante a été nettoyée. Vérifiez les fichiers installés. Ne présumez pas qu’une mise à jour de l’application a supprimé les anciens enregistrements ou approbations.

Vérifiez ce que Postman a écrit avant de le supprimer

Fermez d’abord Postman et les sessions actives des agents. Avant toute modification, conservez des copies privées de la configuration concernée, des enregistrements d’installation et des journaux utiles.

Utilisez le répertoire racine de configuration de la session concernée. Un terminal et une application de bureau peuvent avoir des environnements de lancement différents. La vérification suivante, en Bash, tient compte de CODEX_HOME et de la variable documentée CLAUDE_CONFIG_DIR de Claude Code.

Elle affiche les noms des fichiers contenant une correspondance, pas leur contenu :

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

Une correspondance est une piste à examiner, pas une preuve d’installation automatique. L’absence de correspondance ne concerne que ces fichiers précis.

Pour l’installation macOS décrite dans le signalement, examinez ~/Library/Application Support/Postman/logs/main.log. Le rapport contenait ce résultat d’installation :

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

Comparez son horodatage avec les enregistrements d’installation des plugins. Une chronologie concordante apporte davantage de preuves que le seul mot « Postman » dans un fichier de configuration.

Dans Codex, examinez séparément ces trois entrées du signalement initial :

Entrée de configuration	Point à vérifier
`[marketplaces.postman]`	La source est-elle `https://github.com/postmanlabs/postman-plugin.git` ?
`[plugins."postman@postman"]`	Le plugin est-il activé ?
`[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]`	Une approbation enregistrée contient-elle `trusted_hash`, `trusted_content_hash` ou les deux ?

L’absence d’une entrée d’approbation n’exclut pas la présence du plugin. Le signalement ultérieur illustrait cette différence.

Dans Claude Code, examinez enabledPlugins dans ~/.claude/settings.json. L’identifiant signalé était postman@claude-plugins-official. Dans ~/.claude/plugins/installed_plugins.json, vérifiez la portée, la version, installedAt et lastUpdated de l’installation correspondante.

Pour Cursor, l’adaptateur de l’installateur indique deux emplacements :

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

Utilisez-les comme points de départ. Confirmez l’état d’activation dans les paramètres des plugins de Cursor, plutôt que de le déduire de la présence d’un répertoire.

Gardez privés les fichiers de configuration et les journaux complets. Ils peuvent contenir des identifiants d’authentification, des chemins internes ou des informations de compte. Partagez seulement les entrées pertinentes, après avoir masqué les données sensibles.

Supprimez séparément le plugin et son approbation enregistrée

Choisissez les commandes intégrées à l’outil ou le programme de suppression de Postman. N’exécutez pas systématiquement toutes les méthodes.

Utilisez les commandes de chaque outil pour une suppression ciblée

Pour l’identifiant du plugin Codex cité dans le signalement, exécutez ceci en Bash :

codex plugin remove postman@postman

Ensuite, vérifiez l’origine de son marketplace. Supprimez ce catalogue uniquement si aucun plugin que vous souhaitez conserver ne l’utilise :

codex plugin marketplace remove postman

Ces opérations correspondent à l’adaptateur Postman actuel pour Codex. Si une ancienne installation porte un autre identifiant, utilisez ceux réellement présents sur votre ordinateur.

Pour l’installation Claude Code de portée utilisateur décrite dans le signalement :

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

La référence des commandes de plugins Claude Code distingue les portées user, project et local. Pour une installation confirmée dans la portée projet ou locale, sélectionnez la portée correspondante depuis ce projet. Coordonnez avec l’équipe la suppression de paramètres partagés du projet.

Ne supprimez pas tout le marketplace claude-plugins-official pour retirer un seul plugin. Ne videz pas installed_plugins.json et ne remplacez pas votre fichier de paramètres complet.

Si la CLI installée refuse une commande, consultez son plugin --help avant de continuer. Ne remplacez pas une commande de désinstallation non prise en charge par une suppression massive de répertoires.

Autre méthode : utilisez le programme de suppression documenté par Postman

Les instructions actuelles du dépôt Postman fournissent cette commande de suppression :

npx @postman/postman-plugin@latest remove

N’utilisez cette méthode qu’après avoir examiné et approuvé le code du paquet et vérifié quels agents seront concernés. Le code actuel de l’installateur nécessite Node.js 22 ou ultérieur. Conservez la sous-commande remove : lancer l’installateur sans elle n’effectue pas une suppression.

Le programme documenté laisse en place les installations de portée projet. Son implémentation actuelle pour Codex tente aussi de révoquer l’approbation de l’ancien hook de démarrage.

Vérifiez cette dernière opération séparément. L’implémentation de la révocation peut signaler un problème de nettoyage sans faire échouer toute la suppression. Lisez les avertissements et inspectez ensuite le fichier.

Supprimez toute approbation Codex restante

Si la sous-section ci-dessous reste dans la configuration utilisateur Codex concernée, supprimez-la entièrement :

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

Ce bloc identifie la section à supprimer. Ce n’est pas une configuration à ajouter.

Supprimez ensemble les champs trusted_hash et trusted_content_hash de cette section. Arrêtez-vous avant l’en-tête de la table TOML suivante. Laissez intactes les autres entrées de hooks.state.

Lors d’une modification manuelle, ne retirez que les entrées dont l’appartenance à Postman est confirmée. Préservez model_provider, model_providers, base_url, les paramètres d’authentification et les hooks sans rapport. Dans Claude Code, conservez les paramètres env et les autorisations sans rapport avec Postman.

Après la suppression par les commandes intégrées, vérifiez que les enregistrements correspondants du plugin et du marketplace ont disparu. Quelle que soit la méthode, vérifiez aussi que l’approbation Postman enregistrée a disparu. Un message de désinstallation ne prouve pas à lui seul ces trois résultats.

Vérifiez Cursor, les entrées MCP distinctes et la CLI

Les installations issues du marketplace Cursor nécessitent une autre action : désinstallez Postman dans Cursor Settings > Plugins, puis redémarrez Cursor. Après chaque méthode de suppression, consultez la liste des plugins de Cursor pour repérer d’éventuelles installations Postman restantes.

Si un avertissement MCP persiste, examinez la configuration du serveur au lieu de vous connecter pour le faire disparaître. Dans Bash, utilisez la commande de chaque outil concerné :

codex mcp list
claude mcp list

Un serveur configuré séparément doit aussi être supprimé séparément. Confirmez que l’entrée autonome indésirable porte le nom postman. Utilisez ensuite codex mcp remove postman ou claude mcp remove postman. Vérifiez sa portée avant de la supprimer. La référence de Codex CLI et la documentation MCP de Claude Code décrivent ces commandes.

Ne confondez pas un serveur autonome avec un serveur fourni par un plugin activé. Pour une connexion fournie par un plugin, supprimez le plugin auquel elle appartient.

Vérifiez séparément la CLI Postman. Dans Bash, type -a postman affiche les commandes correspondantes trouvées dans votre chemin de recherche. Dans le cas initial, l’exécutable se trouvait sous ~/.local/bin ; toutes les installations n’utilisent pas nécessairement cet emplacement.

Suivez les instructions de désinstallation de la CLI adaptées à la méthode d’installation. Pour une installation effectuée autrement qu’avec npm, la méthode documentée consiste à supprimer l’exécutable. Inspectez les fichiers qui l’accompagnent avant de les effacer. Ne supprimez jamais un répertoire lib partagé simplement parce que le signalement en mentionne un.

Vérifiez le nettoyage dans une nouvelle session

Vérifiez la configuration et les composants chargés, pas seulement la disparition d’un avertissement.

Commencez par consulter les inventaires de plugins des outils concernés :

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

Recherchez tous les enregistrements Postman, y compris les installations ayant un autre suffixe de marketplace ou une autre portée. Confirmez l’absence de la sous-section exacte d’approbation du hook Postman dans la configuration Codex active.

Lancez une nouvelle session de l’agent dans une copie de travail jetable du dépôt. Vérifiez qu’aucun plugin ni aucune connexion MCP Postman indésirable ne se charge. L’intégration supprimée ne devrait plus produire de nouvel avertissement d’authentification Postman.

Ne prenez pas les références à Postman dans une ancienne conversation comme seule vérification. Le texte d’une conversation et la configuration installée sont distincts. La différence entre ouvrir une nouvelle session Claude Code et compacter une session existante compte ici.

Si Postman apparaît encore, vérifiez le répertoire de configuration, la portée d’installation, les enregistrements de plugins restants et les entrées MCP distinctes. Ne supprimez pas plusieurs fois le même fichier par défaut sans trouver la source active.

Si vous conservez l’application Postman, comparez à nouveau la configuration après son prochain lancement ou sa prochaine mise à jour contrôlés. Si les entrées reviennent, conservez les nouveaux horodatages des journaux et les différences de configuration. Suspendez ce déploiement de l’application pendant que vous cherchez quel processus a recréé ces entrées.

Pourquoi l’installateur pouvait-il écrire l’approbation d’un hook Codex ?

L’ancien installateur utilisait l’interface de configuration de Codex pour enregistrer une approbation. Il ne se limitait pas à inscrire le plugin en laissant la décision de confiance à la vérification interactive.

Au commit 6c8e452e0f4237f4bcc0901cb1ac442dec707e49, l’enregistrement du hook utilisait SessionStart avec matcher défini sur startup|clear|compact. Son texte d’instructions imposait de passer par postman:api-engineer pour les tâches non triviales d’ingénierie des API.

Cette instruction dépassait les demandes explicites d’utilisation de Postman. Elle exemptait les simples questions et les modifications triviales, tout en donnant priorité aux instructions de l’utilisateur.

L’ancienne implémentation de approvePostmanHook lançait codex app-server. Elle obtenait le hash actuel du hook via hooks/list, le vérifiait, puis appelait config/batchWrite. Cette écriture ajoutait trusted_hash sous hooks.state.

Cela établit une tentative d’approbation. Cela ne prouve ni sa réussite sur toutes les versions de Codex, ni l’identité du créateur d’un enregistrement déjà présent sur un ordinateur.

Le mécanisme de confiance documenté de Codex compare un hook à son hash enregistré. Il ignore les hooks nouveaux ou modifiés tant qu’ils n’ont pas été vérifiés et approuvés. La limite importante est donc l’accès à l’état d’approbation. Un hash concordant ne prouve pas, à lui seul, qu’une personne a approuvé le hook.

La conséquence pratique concerne les droits locaux : un logiciel ayant suffisamment accès à la configuration de l’agent peut modifier des paramètres de sécurité. L’activation du plugin, l’approbation du hook et l’authentification MCP distante sont des contrôles distincts. En supprimer un seul peut laisser les autres configurés.

Empêchez de nouvelles modifications sur les postes de l’équipe

Conservez une configuration de référence approuvée, sans données sensibles, puis comparez-la après l’installation et la mise à jour des outils. Placez les modèles et les changements examinés sous contrôle de version, pas les identifiants actifs ni les répertoires personnels complets.

Les différences entre fichiers détectent les changements. Elles n’empêchent pas un processus du même compte d’écrire dans ces fichiers. Pour imposer des restrictions, déployez des politiques contrôlées par les administrateurs que les applications de bureau ordinaires ne peuvent pas réécrire.

Sur macOS ou Linux, le fichier d’exigences système de Codex est /etc/codex/requirements.toml. Ajoutez ce paramètre au niveau supérieur du fichier existant :

allow_managed_hooks_only = true

La documentation de configuration administrée précise les emplacements de déploiement. La référence de configuration définit ce réglage : il ignore les hooks utilisateur, projet, session et plugins, mais autorise les hooks administrés.

Pour Claude Code sur macOS, ajoutez le paramètre suivant à /Library/Application Support/ClaudeCode/managed-settings.json :

{
  "allowManagedHooksOnly": true
}

Il s’agit d’un paramètre de politique administrée, pas d’un remplacement des modifications dans les préférences utilisateur. Les contrôles de hooks de Claude Code bloquent les hooks utilisateur, projet et les autres hooks de plugins. La référence des paramètres conserve des exceptions importantes : hooks administrés, hooks SDK et hooks de plugins activés de force via enabledPlugins dans les paramètres administrés.

Testez les politiques avec les versions des clients réellement utilisées dans l’équipe avant de les déployer plus largement. Les restrictions de hooks ne désinstallent pas les plugins et ne suppriment pas les connexions MCP ; gérez ces composants séparément.

Étendez cette vérification aux fichiers d’instructions téléchargés et aux réglages du fournisseur. L’audit de configuration Codex et Claude Code propose une liste de vérifications plus large pour repérer les changements sans perdre une configuration de modèle fonctionnelle.