Aller au contenu
InYourGeek
visiteur@inyourgeek — console
↹ compléter↑↓ historique⏎ ouvrirhelp
EN

La lettre du lundi · la semaine tech et sécurité en un e-mail

Gratuit, chaque lundi, via Brevo (UE), désinscription en un clic · vos données et vos droits

Logiciel· 3 min de lecture

Postman installe ses greffons dans Claude Code et Codex sans demander

Selon un ticket GitHub ouvert le 25 octobre 2026, Postman 12.33.4 a installé de lui-même des greffons dans Claude Code et Codex, avec un hook de démarrage que son installateur tente d'approuver seul. Si vous utilisez ces agents de code, leur configuration a peut-être changé sans vous.

Un ordinateur portable allumé dans un bureau sombre. Des vrilles mécaniques dorées sortent d'un petit colis posé sur le clavier et se branchent sur plusieurs fenêtres de terminal flottantes. L'une d'elles ouvre elle-même le cadenas d'une fenêtre avec une clé.

Ouvrir Postman, modifier tout le reste

Le ticket n° 14370 a été ouvert le 25 octobre 2026 sur le dépôt de support de Postman, puis relayé sur Hacker News le 3 novembre. Il part d’un constat banal. Après avoir lancé Postman sur son Mac, son auteur voit ses agents de code changer de comportement : Codex affiche des avertissements d’authentification MCP à répétition et fait passer le moindre travail sur une API par des « skills » Postman.

L’enquête qui suit est méthodique. Le journal de Postman lui-même enregistre, le 24 octobre 2026 à 09:34 UTC, une installation automatique marquée auto-existing-upgrade, avec deux résultats : claude-code:installed et codex:installed. La version en cause est Postman desktop 12.33.4. Pour l’auteur, un client d’API n’a pas à devenir le flux de travail par défaut d’autres outils simplement parce qu’on l’a ouvert.

Un hook qui s’invite à chaque session

Côté Codex, le fichier de configuration global ~/.codex/config.toml a gagné trois choses : une place de marché qui pointe vers le dépôt postman-plugin sur GitHub, le greffon postman@postman activé (version 1.1.0) et une entrée de confiance pour un hook. Ce hook se déclenche au démarrage d’une session, mais aussi après un clear ou un compact. Il injecte une consigne : avant toute tâche d’ingénierie d’API non triviale (conception, implémentation, mock, test, supervision, documentation, déploiement), l’agent doit « load the postman:api-engineer skill and follow it ».

C’est un peu comme si votre client mail laissait chaque matin un mot à votre IDE pour lui demander de passer par lui dès qu’il croise une adresse. La consigne va bien au-delà du cas où l’utilisateur demande explicitement Postman.

Claude Code est touché aussi : ~/.claude/settings.json active postman@claude-plugins-official, en version 2.0.1, installé à l’échelle de l’utilisateur. Un exécutable Postman et son dossier lib sont aussi apparus dans ~/.local/bin, avec des dates de modification qui correspondent à la fenêtre d’installation.

L’installateur qui se fait confiance

Le point le plus sérieux se trouve dans le code source du greffon. Juste après l’installation, l’installateur pour Codex appelle une fonction approvePostmanHook. Celle-ci récupère l’empreinte du hook et l’inscrit comme approuvée dans la configuration. Le commentaire du code ne prend pas de détour : « Approves only Postman’s current hook after installation ». Le visiteur imprime donc lui-même son badge d’accès à l’accueil, avec la mention « visiteur de confiance ».

L’auteur du ticket reste prudent. Le code établit la tentative d’approbation, mais l’enregistrement de confiance présent sur sa machine ne prouve pas, à lui seul, qui l’a créé. Il qualifie tout de même l’ensemble de « severe consent and trust-boundary problem ».

Enfin, un serveur MCP distant, https://mcp.postman.com/mcp, a été activé sans connexion authentifiée qui fonctionne. Les journaux de Codex montrent un démarrage en échec, faute d’authentification, ce qui explique les avertissements à répétition. L’extrait du ticket que nous avons consulté ne fait état d’aucune donnée transmise : la connexion échoue avant.

Où regarder sur votre machine

Le ticket, toujours ouvert, ne décrit pas de procédure officielle de désactivation, et l’extrait consulté ne contient pas de réponse de Postman. Il donne en revanche la carte précise des modifications. Si vous avez ouvert Postman récemment sur macOS, c’est elle qu’il faut suivre :

  • dans ~/.codex/config.toml, les sections marketplaces.postman, plugins."postman@postman" et l’entrée hooks.state liée à Postman ;
  • dans ~/.claude/settings.json, l’activation de postman@claude-plugins-official, et sa trace dans ~/.claude/plugins/installed_plugins.json ;
  • dans ~/.local/bin, l’exécutable Postman et son dossier lib ;
  • dans ~/Library/Application Support/Postman/logs/main.log, la ligne qui dit si l’installation automatique a eu lieu chez vous.

Postman voulait devenir le réflexe de vos agents. Il risque surtout de devenir le premier dossier qu’on inspecte après chaque mise à jour.

Sources (1)

PartagerXLinkedInFacebookBluesky

Article rédigé avec l'assistance d'une IA à partir des sources citées, puis relu et validé avant publication par Sébastien Soulier.

La lettre du lundi

La semaine tech et sécurité, chaque lundi dans votre boîte

Ce qu’il faut corriger en premier, les fuites de données, les articles en images. Gratuit, sans pub, désinscription en un clic.

Gratuit, chaque lundi, via Brevo (UE), désinscription en un clic · vos données et vos droits