Plugin de Postman en Codex y Claude Code: revisar y eliminar

Si tienes un plugin de Postman no deseado en Codex o Claude Code, guarda una copia de la configuración y desinstálalo. Elimina también cualquier aprobación guardada del hook de Codex. No autentiques una conexión MCP de Postman que no hayas elegido.

Comprueba el resultado en una sesión nueva antes de retomar el trabajo habitual.

El síntoma descrito en la incidencia #14370 de Postman era este:

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

El autor también describió la carga repetida de habilidades de Postman durante tareas con API. Estos síntomas justifican revisar la integración. No demuestran que se hayan subido datos de las API.

¿Qué cambió después de los primeros informes?

A fecha de 2026-11-10, la respuesta incluye un anuncio de reversión y cambios en el plugin de Codex. No asumas que el comportamiento del instalador original sigue describiendo todas las instalaciones actuales.

El primer informe se refería a Postman para escritorio 12.33.4 en macOS, con el plugin de Codex 1.1.0 y el de Claude Code 2.0.1. Un informe posterior sobre 12.35.1 describió otra instalación automática. Sin embargo, ese equipo no tenía un registro de confianza del hook de Codex, y el plugin de Cursor ya existía.

El 5 de noviembre, preethammavin, miembro del repositorio, anunció que Postman estaba revirtiendo el cambio. Su comentario se distingue de otros anteriores cuyos autores no tenían una asociación de miembro en GitHub.

También el 5 de noviembre se integró la pull request #149, que eliminó la aprobación desde el instalador. Además, borró hooks/codex-hooks.json y estableció "hooks": {} en el manifiesto de Codex. El manifiesto actual de Codex conserva esa declaración vacía de hooks. Sigue incluyendo las habilidades de Postman y un servidor MCP.

Estos cambios no demuestran que una instalación existente haya quedado limpia. Revisa los archivos instalados. No des por hecho que una actualización de escritorio eliminó registros antiguos o aprobaciones de confianza.

Revisa qué escribió Postman antes de eliminarlo

Cierra primero Postman y las sesiones activas de los agentes. Antes de editar, guarda copias privadas de la configuración afectada, los registros de instalación y los logs pertinentes.

Usa el directorio raíz de configuración de la sesión afectada. El entorno de inicio de una terminal puede diferir del de una aplicación de escritorio. Esta comprobación en Bash respeta CODEX_HOME y la variable documentada CLAUDE_CONFIG_DIR de Claude Code.

Imprime los nombres de los archivos con coincidencias, no su contenido:

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

Una coincidencia es una pista para investigar, no una prueba de instalación automática. La ausencia de coincidencias solo se refiere a estos archivos.

Para la instalación de macOS descrita, revisa ~/Library/Application Support/Postman/logs/main.log. La incidencia incluía este resultado de instalación:

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

Compara su marca de tiempo con los registros de instalación de los plugins. Una cronología coincidente aporta más evidencia que encontrar la palabra «Postman» en un archivo de configuración.

En Codex, revisa estas tres entradas independientes del informe original:

Entrada de configuración	Qué comprobar
`[marketplaces.postman]`	Si su origen es `https://github.com/postmanlabs/postman-plugin.git`.
`[plugins."postman@postman"]`	Si el plugin está habilitado.
`[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]`	Si una aprobación guardada contiene `trusted_hash`, `trusted_content_hash` o ambos.

La ausencia de una entrada de confianza no descarta que el plugin esté instalado. El informe posterior mostró esa diferencia.

En Claude Code, revisa enabledPlugins en ~/.claude/settings.json. El identificador del informe era postman@claude-plugins-official. En ~/.claude/plugins/installed_plugins.json, comprueba el ámbito, la versión, installedAt y lastUpdated de la instalación correspondiente.

Para Cursor, el adaptador del instalador identifica dos ubicaciones:

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

Úsalas como puntos de partida para investigar. Confirma si el plugin está habilitado en los ajustes de Cursor, en vez de deducirlo solo por la presencia de un directorio.

Mantén privados los archivos completos de configuración y los logs. Pueden contener credenciales, rutas internas o información de cuentas. Comparte únicamente las entradas pertinentes, después de ocultar los datos sensibles.

Elimina por separado el plugin y su aprobación guardada

Elige entre los comandos propios del agente y la herramienta de eliminación de Postman. No ejecutes todas las vías de forma automática.

Usa los comandos propios del agente para una eliminación específica

Para el identificador del plugin de Codex que aparece en el informe, ejecuta esto en Bash:

codex plugin remove postman@postman

Después, elimina su marketplace solo cuando hayas confirmado el origen y comprobado que ningún plugin que necesites lo utiliza:

codex plugin marketplace remove postman

Estas operaciones coinciden con el adaptador actual de Postman para Codex. Si una instalación anterior usa otro registro, utiliza los identificadores que realmente aparecen en tu equipo.

Para la instalación de Claude Code en el ámbito de usuario descrita en el informe:

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

La referencia de comandos de plugins de Claude Code distingue los ámbitos user, project y local. Si confirmas una instalación en el ámbito de proyecto o local, selecciona ese ámbito desde el proyecto correspondiente. Coordina con el equipo la eliminación de ajustes compartidos del proyecto.

No elimines todo el marketplace claude-plugins-official para quitar un solo plugin. No vacíes installed_plugins.json ni sustituyas todo el archivo de configuración.

Si la CLI instalada rechaza un comando, consulta su plugin --help antes de continuar. No sustituyas un comando de desinstalación no compatible por el borrado indiscriminado de directorios.

Alternativa: usa la herramienta de eliminación documentada por Postman

Las instrucciones actuales del repositorio de Postman ofrecen este comando de eliminación:

npx @postman/postman-plugin@latest remove

Usa esta vía solo después de revisar y aprobar el código del paquete y comprobar qué agentes afectará. El código actual del instalador requiere Node.js 22 o posterior. Conserva el subcomando remove: ejecutar el instalador sin él no es una operación de limpieza.

La herramienta documentada deja intactas las instalaciones en el ámbito de proyecto. Su implementación actual para Codex también intenta revocar la aprobación del antiguo hook de inicio.

Comprueba por separado esa última operación. La implementación de la revocación puede informar de un problema de limpieza sin hacer que falle toda la eliminación. Lee sus advertencias y revisa el archivo después.

Elimina cualquier aprobación de Codex que permanezca

Si la siguiente subsección sigue en la configuración de usuario de Codex afectada, elimínala por completo:

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

Este bloque identifica la sección que debes eliminar. No es una configuración que debas añadir.

Borra juntos los campos trusted_hash y trusted_content_hash de esa sección. Detente antes de la siguiente cabecera de tabla TOML. Deja intactas las demás entradas de hooks.state.

Cuando edites manualmente, elimina solo las entradas que hayas confirmado que pertenecen a Postman. Conserva model_provider, model_providers, base_url, los ajustes de autenticación y los hooks ajenos a Postman. En Claude Code, conserva los ajustes de env y permisos que no estén relacionados.

Después de usar los comandos propios del agente, comprueba que desaparecieron los registros correspondientes del plugin y del marketplace. Con cualquiera de las dos vías, verifica que también desapareció la aprobación guardada de Postman. Un mensaje de desinstalación no demuestra por sí solo las tres condiciones.

Revisa Cursor, las entradas MCP independientes y la CLI

Las instalaciones del marketplace de Cursor requieren otro paso: desinstala Postman en Cursor Settings > Plugins y reinicia Cursor. Después de cualquiera de las vías de eliminación, revisa la lista de plugins de Cursor para detectar instalaciones restantes de Postman.

Si persiste una advertencia de MCP, revisa la configuración del servidor en vez de iniciar sesión para silenciarla. En Bash, usa el comando correspondiente a cada agente afectado:

codex mcp list
claude mcp list

Un servidor configurado por separado también requiere una eliminación independiente. Confirma que la entrada independiente no deseada se llama postman. Después usa codex mcp remove postman o claude mcp remove postman. Comprueba el ámbito de la entrada antes de eliminarla. La referencia de Codex CLI y la documentación de MCP de Claude Code describen estos comandos.

No confundas un servidor independiente con uno proporcionado por un plugin habilitado. Para una conexión proporcionada por un plugin, elimina el plugin al que pertenece.

Comprueba la CLI de Postman por separado. En Bash, type -a postman muestra los comandos coincidentes que encuentra en tu ruta de búsqueda. En el incidente original, el ejecutable estaba en ~/.local/bin; no asumas que todas las instalaciones utilizan esa ubicación.

Sigue las instrucciones de desinstalación de Postman CLI según el método de instalación. Para una instalación que no se hizo con npm, el método documentado elimina el ejecutable. Revisa los archivos que lo acompañan antes de borrarlos. Nunca elimines un directorio lib compartido solo porque el informe lo menciona.

Comprueba la limpieza en una sesión nueva

Verifica la configuración y los componentes cargados, no solo la ausencia de una advertencia.

Primero, consulta los inventarios de plugins de los agentes afectados:

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

Busca todos los registros de Postman, incluidas instalaciones con otro sufijo de marketplace o ámbito. Confirma que la subsección exacta de aprobación del hook de Postman no aparece en la configuración activa de Codex.

Inicia una sesión nueva del agente en una copia de trabajo desechable del repositorio. Comprueba que no se carga ningún plugin ni conexión MCP de Postman que no quieras. La integración eliminada no debería generar una nueva advertencia de autenticación de Postman.

No uses las referencias a Postman de una conversación antigua como única prueba. El texto de una conversación y la configuración instalada son elementos distintos. Por eso importa la diferencia entre iniciar una sesión nueva de Claude Code y compactar una existente.

Si Postman sigue apareciendo, revisa el directorio de configuración, el ámbito de instalación, los registros de plugins restantes y las entradas MCP independientes. No borres repetidamente el mismo archivo predeterminado sin localizar el origen activo.

Si conservas Postman para escritorio, vuelve a comparar la configuración después de su siguiente inicio o actualización controlados. Si reaparecen entradas, guarda las nuevas marcas de tiempo del log y las diferencias de configuración. Pausa ese despliegue de la aplicación de escritorio mientras investigas qué proceso las recreó.

¿Por qué podía el instalador escribir la confianza de un hook de Codex?

El instalador antiguo utilizaba la interfaz de configuración de Codex para guardar una aprobación. No se limitaba a registrar el plugin y dejar la decisión de confianza a la revisión interactiva.

En el commit 6c8e452e0f4237f4bcc0901cb1ac442dec707e49, el registro del hook utilizaba SessionStart con el matcher startup|clear|compact. Su texto de instrucciones dirigía las tareas no triviales de ingeniería de API a postman:api-engineer.

La instrucción abarcaba más que las peticiones explícitas de usar Postman. Exceptuaba las consultas sin acciones y las ediciones triviales, y daba prioridad a las instrucciones del usuario.

La implementación antigua de approvePostmanHook iniciaba codex app-server. Obtenía el hash actual del hook mediante hooks/list, lo comprobaba y llamaba a config/batchWrite. Esa escritura insertaba trusted_hash en hooks.state.

Esto demuestra un intento de aprobación. No demuestra que funcionara en todas las versiones de Codex ni identifica quién creó el registro existente de un equipo concreto.

El mecanismo de confianza documentado de Codex compara un hook con su hash guardado. Los hooks nuevos o modificados no se ejecutan mientras esperan revisión y aprobación. Por tanto, el límite importante es el acceso al estado de aprobación. Un hash coincidente no demuestra por sí solo que una persona haya aprobado el hook.

La implicación práctica es local: un programa con suficiente acceso a la configuración del agente puede cambiar ajustes relevantes para la seguridad. La habilitación del plugin, la confianza del hook y la autenticación MCP remota son controles separados. Eliminar solo uno puede dejar configurados los demás.

Evita nuevos cambios en los equipos del grupo

Mantén una configuración de referencia aprobada y sin datos sensibles. Compárala después de instalar o actualizar herramientas. Guarda plantillas y cambios revisados en el control de versiones, no credenciales activas ni directorios completos de configuración personal.

Las diferencias entre archivos detectan cambios, pero no impiden que un proceso de la misma cuenta escriba en ellos. Para aplicar restricciones, utiliza políticas controladas por administradores que las aplicaciones de escritorio normales no puedan reescribir.

En macOS o Linux, el archivo de requisitos del sistema de Codex es /etc/codex/requirements.toml. Añade este ajuste en el nivel superior del archivo existente:

allow_managed_hooks_only = true

La documentación de configuración administrada describe las ubicaciones de despliegue. La referencia de configuración define el ajuste: omite los hooks de usuario, proyecto, sesión y plugins, pero permite los administrados.

Para Claude Code en macOS, incorpora lo siguiente a /Library/Application Support/ClaudeCode/managed-settings.json:

{
  "allowManagedHooksOnly": true
}

Este es un ajuste de política administrada, no un sustituto de editar las preferencias del usuario. Los controles de hooks de Claude Code bloquean los hooks de usuario, proyecto y otros plugins. Su referencia de ajustes mantiene excepciones importantes: hooks administrados, hooks del SDK y hooks de plugins habilitados obligatoriamente mediante enabledPlugins administrado.

Prueba las políticas con las versiones reales de los clientes del equipo antes de desplegarlas ampliamente. Las restricciones de hooks no desinstalan plugins ni eliminan conexiones MCP; controla esos componentes por separado.

Extiende la revisión a las instrucciones descargadas y los ajustes del proveedor. La auditoría de configuración de Codex y Claude Code ofrece una lista más amplia para identificar cambios sin descartar una configuración de modelo que funciona.