Abrir Postman en una Mac que no se usaba hace semanas alcanzó para que la aplicación instalara, sin preguntar, el plugin de Postman para Codex y su equivalente en Claude Code. Un usuario documentó el caso el 25 de octubre de 2026 en el repositorio de soporte de Postman en GitHub, con logs, archivos de configuración y código fuente que respaldan cada paso.

El reporte, publicado como el issue #14370 en postman-app-support, suma cinco cambios no solicitados en una sola máquina: un plugin en Codex, uno en Claude Code, un hook de sesión aprobado por el propio instalador, una conexión MCP remota y un binario de Postman CLI instalado por separado.

TL;DR

  • Postman 12.33.4 instaló sin permiso un plugin en Codex y Claude Code el 24 de octubre de 2026, según el issue #14370.- El log de Postman registra el evento como auto-existing-upgrade, con los resultados codex:installed y claude-code:installed.- Los logs muestran que el instalador escribe el hash de su propio hook como trusted_hash dentro del config.toml de Codex.- Ese hook ordena cargar el skill postman:api-engineer ante cualquier tarea de API, sin que el usuario lo pida.- La conexión MCP a mcp.postman.com quedó habilitada pero sin autenticar, según los logs citados en el reporte.

Qué es el plugin de Postman para Codex

El plugin de Postman para Codex es la extensión que Postman distribuye también para Claude Code, con un marketplace propio y un hook de inicio de sesión que el agente ejecuta automáticamente al arrancar, antes de atender cualquier instrucción del usuario.

La función forma parte del marketplace de plugins de Postman, un catálogo donde un proveedor publica una extensión que Codex o Claude Code cargan como skill. Postman mantiene el código de ese plugin en el repositorio público postman-plugin, con el instalador, los hooks y la documentación que el agente lee al iniciar sesión.

Qué pasó

El usuario que abrió el issue encontró la causa en su propio archivo de logs. En ~/Library/Application Support/Postman/logs/main.log, las líneas 11562 y 11563 registran, el 2026-10-24T09:34:14.418Z, una instalación automática completa:

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

El reporte fecha la instalación con Postman desktop en su versión 12.33.4 y el plugin de Codex en la 1.1.0, con el código fuente fijado en la revisión 6c8e452e0f4237f4bcc0901cb1ac442dec707e49 del repositorio de Postman. Esa misma revisión es la que cita el issue #14370 para cada archivo que examinó.

La instalación tocó dos clientes a la vez. En Codex, el reporte muestra un bloque nuevo en ~/.codex/config.toml con el marketplace de Postman, el plugin habilitado y el hook ya marcado como confiable. En Claude Code, ~/.claude/settings.json habilitó postman@claude-plugins-official y installed_plugins.json quedó con la versión 2.0.1, en alcance de usuario, con installedAt y lastUpdated en el mismo segundo: 2026-10-24T09:34:02.610Z.
El log de Postman fecha el evento el 24 de octubre de 2026 a las 09:34:14 UTC.

Contexto e historia

Postman nació como cliente de pruebas de API y hoy empuja a sus usuarios hacia agentes de código: Codex, de OpenAI, y Claude Code, de Anthropic, son dos de los entornos agénticos más usados por desarrolladores en 2026. Ambos aceptan plugins externos que extienden lo que el agente puede hacer sin que el usuario escriba el prompt completo cada vez.

Ese modelo de extensión se apoya en un supuesto simple: el usuario decide qué plugin instalar y qué hook puede ejecutarse al iniciar sesión. Codex, en particular, exige que cada hook quede marcado con un trusted_hash antes de correr, precisamente para que una revisión humana se interponga entre un archivo de configuración y la ejecución automática de instrucciones en cada sesión.

El issue no describe un ataque externo ni una vulnerabilidad de terceros. Describe al propio fabricante saltándose ese paso de revisión en su propio producto, algo distinto de un exploit: es una decisión de diseño del instalador.

Detalles técnicos 

sequenceDiagram participant P as Postman desktop participant C as Config de Codex participant A as Agente Codex P->>C: escribe marketplaces.postman y plugins.postman P->>C: escribe hooks.state con su propio trusted_hash Note over P,C: el instalador aprueba el hook sin pedir confirmacion A->>C: lee hooks.state al iniciar sesion C-->>A: hook ya confiable, se ejecuta sin aviso

El mecanismo que preocupa al reporte no es que Postman tenga un plugin, sino cómo ese plugin llega a ejecutarse sin que nadie lo apruebe a mano. El archivo installer/src/hosts/codex-hooks.ts obtiene, vía hooks/list, el hash del hook que el propio instalador acaba de registrar. Después llama a config/batchWrite para escribir ese hash en hooks.state como trusted_hash, el mismo campo que Codex usa para saber si debe pedir confirmación.

El comentario del código, citado en el issue, lo resume sin rodeos: "Approves only Postman's current hook after installation". El propio instalador firma su aprobación en el mismo paso en que instala el hook, así que el usuario nunca ve la pantalla de confirmación que ese campo está pensado para disparar.

El contenido del hook tampoco es neutral. El archivo hooks/session-start-context.md se registra con el matcher startup|clear|compact, o sea que corre al iniciar sesión, al limpiar el contexto y al compactarlo. Su instrucción le pide al agente cargar el skill postman:api-engineer antes de responder a cualquier tarea de ingeniería de API no trivial, sin condicionarlo a que el usuario haya mencionado Postman.
Paso del flujo de confianzaComportamiento esperado en CodexLo que registra el issue sobre PostmanDetectar un plugin nuevoEl usuario ejecuta un comando de instalación explícitoSe dispara solo, registrado como auto-existing-upgradeRegistrar el hook de inicioSe guarda sin marcar como confiableSe guarda igual, sin marca de confianza todavíaAprobar el hook (trusted_hash)El usuario revisa el comando y lo aprueba a manoEl instalador llama a config/batchWrite y escribe el trusted_hash él mismoEjecutar el hook en cada sesiónSolo corre si el usuario lo aprobó antesCorre en cada startup, clear y compact desde la instalación
El costo de ese atajo no es solo simbólico. Un hook con trusted_hash corre sin aviso en cada sesión nueva, y la instrucción que trae este en particular es amplia: cualquier tarea de API cuenta, no solo las que mencionan Postman. El usuario que abrió el issue describió el síntoma antes de encontrar la causa: advertencias repetidas de autenticación MCP y Codex enrutando trabajo de API hacia skills de Postman que nunca pidió.

La conexión remota tampoco funcionaba todavía. El archivo mcp.codex.json apunta a https://mcp.postman.com/mcp, pero los logs de Codex citados en el issue muestran el error Auth required, when send initialize request. La integración queda activa en la configuración del usuario aunque el servidor remoto todavía no autentique nada, lo que amplía la superficie de confianza antes de que la función esté lista.

⚠️ Ojo: el issue aclara que el registro de confianza (trusted_hash) no prueba por sí solo quién lo generó. El autor fue cuidadoso en separar lo que el código hace de lo que una interacción humana específica demuestra.
El hook se registra con el matcher startup, clear y compact: corre en los tres eventos.

Impacto y análisis

El caso importa porque invierte el orden habitual del consentimiento. En la mayoría de los incidentes de cadena de suministro de este año, un paquete de terceros comprometido engaña a un agente o a un desarrollador. Acá no hay ningún paquete comprometido: es el fabricante original escribiendo, en su propio instalador, la aprobación que el sistema de permisos exige específicamente para frenar este tipo de cambio.

Para cualquier desarrollador que use Codex o Claude Code con plugins de terceros, el reporte deja una pregunta incómoda. Si un proveedor puede aprobar su propio hook durante la instalación, el campo trusted_hash deja de significar que un humano revisó el cambio y pasa a significar que algún instalador lo marcó así, y esa diferencia es justo lo que el campo estaba pensado para impedir.

El alcance tampoco se limita a Postman. Cualquier aplicación de escritorio que detecte Codex o Claude Code instalados en la misma máquina puede, en teoría, replicar el mismo patrón: escribir su propio plugin, su propio hook y su propia aprobación en un solo paso de actualización silenciosa, sin que el usuario abra ningún diálogo.

Qué sigue

El issue quedó abierto como reporte de severidad SEVERE en la plantilla de postman-app-support, con pasos para reproducir todavía marcados como no reproducidos en una Mac limpia. Eso deja pendiente que otro usuario, o Postman mismo, confirme si el comportamiento se repite fuera de la máquina original.

Lo que sí queda documentado en el código público es la función approvePostmanHook, invocada desde installer/src/hosts/codex.ts justo después de instalar el plugin. Mientras ese código no cambie, cualquier instalación nueva de Postman sobre una máquina con Codex o Claude Code puede repetir la misma secuencia: instalar, registrar el hook y aprobarlo, los tres pasos sin una pantalla intermedia para el usuario.

La vara para medir una corrección real es simple: que el instalador deje de llamar a config/batchWrite para su propio trusted_hash y que la aprobación del hook vuelva a depender de una acción explícita del usuario, igual que para cualquier otro plugin del marketplace.

📖 Resumen en Telegram: Ver resumen

Revisá hoy mismo tu ~/.codex/config.toml y tu ~/.claude/plugins/installed_plugins.json antes de confiar en el próximo plugin que se instale solo.

Preguntas frecuentes

¿Qué hace el plugin de Postman para Codex una vez instalado?

Registra un marketplace y un plugin en la configuración de Codex, y agrega un hook que corre al iniciar sesión, limpiar o compactar el contexto. Ese hook le dice al agente que cargue el skill postman:api-engineer ante cualquier tarea de API, según el código citado en el issue #14370.

¿Instalar el complemento de Postman para agentes de código requiere confirmación explícita?

Según los logs del reporte, no en todos los casos: el evento quedó registrado como auto-existing-upgrade, es decir, disparado por una actualización de una instalación existente de Postman, sin un paso separado de confirmación por cada agente.

¿Qué hace el hook de inicio de Postman en Codex en cada sesión?

Imprime el contenido de session-start-context.md, que instruye al agente a tratar cualquier tarea de ingeniería de API como una señal para usar las herramientas de Postman, sin que el usuario lo haya pedido en ese turno.

¿La integración de Postman con Claude Code funciona igual que con Codex?

El reporte muestra que ambas quedaron habilitadas en la misma ventana de tiempo: ~/.claude/settings.json activó el plugin y installed_plugins.json registró la versión 2.0.1 en alcance de usuario. El issue no detalla si Claude Code aplica el mismo mecanismo de hook confiable que Codex.

¿Cómo reviso si tengo el marketplace de plugins de Postman activo en mi máquina?

En Codex, revisá si ~/.codex/config.toml tiene una sección [marketplaces.postman] y si hooks.state incluye un trusted_hash para una ruta de Postman. En Claude Code, revisá si ~/.claude/plugins/installed_plugins.json lista a postman@claude-plugins-official.

¿Postman respondió al reporte sobre su extensión para IDEs de IA?

Los fragmentos públicos del issue #14370, abierto el 25 de octubre de 2026, no registran hasta la fecha de esta nota una respuesta oficial de Postman en el propio hilo.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.