Postman s’invite dans Claude Code et Codex sans consentement

Un développeur dit avoir découvert que Postman, via sa version desktop 12.33.4 sur macOS, avait installé des plugins dans Claude Code et OpenAI Codex sans autorisation explicite. Le cas, signalé fin octobre 2026 et relayé par The New Stack le 3 novembre, compte parce qu’il touche à un sujet sensible pour les équipes techniques : qui décide vraiment de ce qu’un agent de code peut faire sur une machine de travail. Selon le rapport, Postman a aussi tenté d’approuver son propre hook de démarrage, un mécanisme qui lance des instructions automatiquement au début d’une session. Une petite ligne de configuration peut donc peser lourd.

Des plugins installés, des réglages modifiés

Le signalement émane d’un utilisateur GitHub identifié comme “indicava”. D’après son dépôt, l’ouverture de Postman desktop a déclenché une séquence qui a ajouté des éléments de configuration pour Codex et Claude Code, dont un plugin Postman, un marketplace de plugins et un hook de session marqué comme approuvé. Le développeur dit n’avoir rien validé de son côté. Le rapport mentionne aussi un exécutable Postman CLI créé à un horodatage cohérent avec l’installation. À ce stade, l’incident n’a été reproduit de manière indépendante que sur cette machine macOS [à vérifier].

Le cœur du problème n’est pas seulement l’installation elle-même. Les hooks de session permettent à un outil de lancer des consignes au démarrage d’un agent de code, avant même que l’utilisateur ne commence à taper. Dans ce cas, les instructions de Postman demandent à Codex de charger le profil “postman:api-engineer” pour la plupart des tâches liées aux API. Cela peut être pratique si l’intégration a été voulue. Cela l’est beaucoup moins quand elle apparaît dans un environnement déjà en place, sans opt-in clair.

Le contrôle des agents devient un sujet de sécurité

La polémique a rapidement circulé chez des développeurs et des chercheurs en sécurité. Frank Denis a qualifié les intégrations de “junk” sur X et a pointé le fait que l’installateur semblait faire confiance à son propre hook. D’autres commentaires évoquent un risque en entreprise, où l’ajout silencieux d’un plugin peut modifier un outillage déjà validé par une DSI. The New Stack précise toutefois qu’aucune preuve de vol de données n’apparaît dans le dépôt GitHub : le dossier documente des changements de paramètres d’agent et une connexion MCP distante, pas une exfiltration.

Postman, selon sa documentation citée par le média, peut approuver automatiquement un hook de session pour Codex à l’installation. Dans le flux habituel, un développeur qui ajoute un plugin directement dans Codex est censé revoir et valider ce hook manuellement. La différence est de taille. D’un côté, une approbation explicite. De l’autre, une intégration qui se met à parler toute seule. Dans un outil de développement, le téléphone arabe n’est pas exactement une fonctionnalité de qualité.

Ce que cela dit de l’outillage IA en entreprise

L’affaire dépasse Postman. Elle montre que les agents de codage ne sont plus de simples assistants de saisie, mais des environnements capables de modifier leurs propres règles d’exécution, leurs plugins et leurs connexions. Pour les équipes sécurité comme pour les développeurs, la question devient alors très concrète : comment auditer un agent quand ses réglages, ses hooks et ses droits peuvent évoluer à l’insu de l’utilisateur ? Postman n’avait pas répondu au moment de la publication de l’article source, et le développeur demande un moyen de revenir en arrière complètement, pas seulement une commande de désinstallation.

Pour les entreprises qui commencent à déployer ces outils, le bon réflexe reste simple : vérifier les plugins inconnus, inspecter les hooks de démarrage et contrôler les connexions MCP associées. Dans un contexte où les assistants de code s’installent au cœur des chaînes de dev, la ligne entre confort et intrusion devient de plus en plus fine.