Postman Instalou Plugin no Claude Code e no Codex Sem Pedir: O Que Aconteceu e Como Verificar em 2026

Olá HaWkers, no dia 25 de outubro de 2026 um desenvolvedor abriu a issue #14370 no repositório público de suporte do Postman com um título que não deixa margem para dúvida: "[SEVERE] Desktop auto-installs Codex/Claude plugins; installer attempts to trust its own startup hook". Ele tinha aberto o Postman desktop 12.33.4 no macOS e, sem clicar em nada, ganhou um plugin novo no Codex, outro no Claude Code e uma CLI do Postman em ~/.local/bin. A história subiu para o topo do Hacker News com mais de 1.200 pontos e 400 comentários.

Se você usa agente de código no dia a dia, a pergunta que importa não é se o Postman é vilão. É outra: você saberia dizer, agora, quais plugins, hooks e servidores MCP estão ativos nos seus agentes, e quem colocou cada um lá? Neste artigo eu separo o que foi de fato comprovado do que é exagero de manchete, explico por que o detalhe do hook é o mais grave e mostro scripts para auditar sua máquina em poucos minutos.

O Que Foi Relatado, Com Datas e Versões

Vamos aos fatos, porque eles são mais interessantes que a manchete.

Segundo a issue, o log local do Postman registrou em 24 de outubro de 2026 uma instalação marcada com o rótulo auto-existing-upgrade. Esse nome já diz muito: o caminho de código foi feito para usuários que já tinham o app instalado e receberam uma atualização. Nessa execução entraram três coisas:

o plugin do Postman para o Codex, versão 1.1.0
o plugin do Postman para o Claude Code, versão 2.0.1
a Postman CLI, colocada em ~/.local/bin

Nos dias seguintes outros usuários confirmaram o comportamento. Em 3 de novembro, um relato mostrou a atualização do Postman 12.31.3 para o 12.35.1, também no macOS, passando pelo mesmo caminho auto-existing-upgrade. Dessa vez a CLI chegou na versão 1.85.0, o plugin do Codex aparecia em cache na versão 1.3.0 e o Cursor foi listado como "already-installed". Em 4 de novembro, outro usuário encontrou em ~/.copilot/settings.json um marketplace do Postman e o plugin postman@postman habilitado no GitHub Copilot. E o item de menu "Uninstall Postman Coding Agent Plugin" não removeu essa entrada.

Ou seja: não foi um caso isolado de uma máquina estranha. Foi um comportamento de produto que atingiu várias versões e vários agentes.

O Que a Manchete Exagerou

O título que circulou no Hacker News dizia que o Postman "attempts to share all API data", algo como "tenta compartilhar todos os dados de API". Isso não está comprovado, e quem abriu a issue foi bem cuidadoso em dizer isso. Nas palavras dele, o relato "establishes unwanted integration and instruction changes; it does not claim to establish data exfiltration". Outro usuário escreveu, no relato de 3 de novembro, que não tinha evidência de que algum dado foi enviado.

O único endpoint de rede citado é o servidor MCP remoto em https://mcp.postman.com/mcp, e ele respondia "Auth required". Os usuários viam avisos repetidos de autenticação do MCP, o que indica que a conexão nem chegava a funcionar sem login.

Então, sendo honesto: não há prova de vazamento. O que há é algo diferente, e para quem trabalha com segurança talvez até mais preocupante, porque é estrutural. Um aplicativo mexeu na configuração de outros aplicativos, e esses outros aplicativos são agentes que leem seu código, rodam comandos no seu terminal e têm acesso às suas credenciais.

Por Que o Hook É a Parte Mais Grave

Instalar plugin sem pedir já é ruim. Mas o ponto que fez a issue ganhar o rótulo de "SEVERE" foi outro.

Agentes como o Codex e o Claude Code suportam hooks: comandos que rodam automaticamente em eventos do ciclo de vida, como o início de uma sessão (SessionStart). Como um hook executa código na sua máquina e pode injetar texto no contexto do modelo, o Codex exige que o usuário aprove cada hook novo. A aprovação fica registrada na configuração como um hash de confiança.

Pela leitura que o autor da issue fez do arquivo codex-hooks.ts do instalador, o código do Postman verifica se o Codex já confia no hook e, se não confia, tenta gravar ele mesmo esse registro de confiança. Na prática, o instalador tenta aprovar o próprio hook, pulando justamente a etapa de revisão humana que existe para impedir isso.

E o que o hook faz? Ele imprime, no início de cada sessão, um texto que manda o agente carregar a skill postman:api-engineer para "any non-trivial API engineering task". Não é só quando você pede algo do Postman. É para qualquer tarefa de API.

Pense no que isso significa. Um texto que você não escreveu, vindo de um fornecedor que você não chamou, entra no contexto do seu agente em toda sessão e muda o comportamento dele. Tecnicamente é a mesma mecânica de prompt injection, só que com assinatura de empresa conhecida. Eu escrevi sobre essa mecânica num caso bem diferente no artigo sobre prompt injection em petições e as multas que advogados estão levando, e a lição é a mesma: quem escreve no contexto do modelo controla o modelo.

O hook chegou a rodar?

Aqui os relatos divergem, e vale registrar. Um usuário testou com o Codex 0.162.1 e afirmou que um hook sem registro de confiança persistido é ignorado. Outro, no Codex 0.153.4, não encontrou trusted_hash no config.toml, então o hook não parecia rodar na máquina dele. Isso ainda não foi confirmado de forma independente. A conclusão prática é simples: não presuma. Verifique a sua configuração.

O Que o Plugin do Postman Faz Quando Instalado do Jeito Certo

Para ser justo com o produto: o plugin em si não é malware. Ele existe, é documentado e pode ser útil. A documentação oficial descreve o Postman plugin como um conjunto de skills que ensinam o agente a criar, testar, simular, monitorar e documentar APIs com o Postman, e diz que cada skill só carrega quando a tarefa pede.

São 18 skills, entre elas api-engineer, api-testing, api-mocking, api-documentation, ci-integration, performance-testing e postman-mcp-server. A documentação lista suporte a Claude Code 2.1.268 ou superior, Codex 0.138.0 ou superior, Cursor 2.5 ou superior, GitHub Copilot CLI, Antigravity, Factory Droid, Kimi Code, OpenCode e Pi. E existe um modo oficial de instalação que, com um único comando, instala o plugin em todos os agentes detectados na máquina.

Esse é o mecanismo no centro da polêmica. Quando você roda o comando, é uma escolha sua. Quando o app desktop roda o mesmo fluxo num caminho chamado auto-existing-upgrade, deixa de ser.

Como Auditar Sua Máquina em 5 Minutos

Chega de teoria. O primeiro passo é procurar qualquer referência ao Postman nos arquivos de configuração dos agentes. O script abaixo só lê, não altera nada.

#!/usr/bin/env bash
# Procura referências ao Postman nas configurações dos agentes de código.
# Apenas leitura: nenhum arquivo é alterado.

set -u

# Diretórios e arquivos citados nos relatos e nas configurações padrão
alvos=(
  "$HOME/.codex"
  "$HOME/.claude"
  "$HOME/.copilot"
  "$HOME/.cursor"
)

for alvo in "${alvos[@]}"; do
  [ -e "$alvo" ] || continue
  echo "== $alvo"
  # -r recursivo, -i ignora maiúsculas, -l mostra só o nome do arquivo
  grep -ril "postman" "$alvo" 2>/dev/null | head -50
done

# A CLI instalada pelo app vai para ~/.local/bin
if [ -e "$HOME/.local/bin/postman" ]; then
  echo "== Postman CLI encontrada em $HOME/.local/bin/postman"
  ls -la "$HOME/.local/bin/postman"
fi

Se nada aparecer, ótimo. Se aparecer, não saia apagando. Primeiro entenda o que foi adicionado e se foi você mesmo que instalou em algum momento.

O que procurar no Codex

No relato original, o config.toml do Codex ganhou uma entrada [marketplaces.postman] e o plugin postman@postman habilitado. O script em Node abaixo lista marketplaces, plugins e registros de confiança de hooks, para você ver tudo de uma vez.

// audit-codex.mjs
// Lista marketplaces, plugins e trechos de confiança de hooks no config do Codex.
// Uso: node audit-codex.mjs
import { readFileSync, existsSync } from 'node:fs';
import { homedir } from 'node:os';
import { join } from 'node:path';

const caminho = join(homedir(), '.codex', 'config.toml');

if (!existsSync(caminho)) {
  console.log('Nenhum config do Codex encontrado em', caminho);
  process.exit(0);
}

const linhas = readFileSync(caminho, 'utf8').split('\n');
let secaoAtual = '';

linhas.forEach((linha, i) => {
  const secao = linha.match(/^\s*\[([^\]]+)\]/);
  if (secao) secaoAtual = secao[1];

  // Sinaliza seções de marketplace, plugin e hook
  const interessante =
    /marketplace|plugin|hook/i.test(secaoAtual) ||
    /trusted_hash|postman/i.test(linha);

  if (interessante && linha.trim()) {
    console.log(`${String(i + 1).padStart(4)} [${secaoAtual}] ${linha.trim()}`);
  }
});

O que você quer ver na saída é só aquilo que reconhece. Um marketplace que você nunca adicionou ou um hash de confiança para um hook que você nunca revisou são os dois sinais de alerta.

Como Remover Com Segurança

Se a auditoria encontrou o plugin e você não quer ele, a ordem importa. Remover só o plugin e deixar o hook confiável, ou o marketplace, deixa a porta aberta para uma reinstalação silenciosa na próxima atualização.

A lista que o próprio autor da issue pediu ao Postman serve muito bem como checklist de limpeza: configurações, confiança de hooks, marketplaces, caches, conexões MCP e a CLI. Na prática, eu faço assim:

#!/usr/bin/env bash
# Faz backup das configurações dos agentes ANTES de qualquer limpeza manual.
# Assim dá para comparar e voltar atrás se algo quebrar.

set -euo pipefail

destino="$HOME/agent-config-backup-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$destino"

for alvo in "$HOME/.codex" "$HOME/.claude" "$HOME/.copilot"; do
  if [ -e "$alvo" ]; then
    # Copia preservando permissões e datas
    cp -Rp "$alvo" "$destino/"
    echo "Backup de $alvo em $destino"
  fi
done

echo "Agora edite os arquivos à mão, removendo:"
echo "  1. a seção [marketplaces.postman] e o plugin postman@postman"
echo "  2. qualquer registro de confiança do hook do Postman"
echo "  3. a entrada do servidor MCP mcp.postman.com, se houver"
echo "  4. a CLI em ~/.local/bin/postman, se você não instalou"

No Claude Code, o caminho mais seguro é usar o próprio gerenciador de plugins, pelo comando /plugin, e desabilitar ou desinstalar o plugin do Postman por lá, em vez de apagar pastas na mão. No Copilot, lembre que o relato de 4 de novembro mostrou que o item de menu do Postman não limpou o ~/.copilot/settings.json, então confira o arquivo depois.

E se você usa o Postman e quer continuar usando, vale ficar atento às próximas versões do app. Alguns usuários simplesmente migraram para outros clientes de API, como o Insomnia, mas essa é uma decisão de cada time.

Como Detectar a Próxima Mudança Antes Que Ela Te Pegue

O caso do Postman não vai ser o último. Todo app que quer "integrar com IA" tem incentivo para se plugar no seu agente. A defesa que funciona é ter uma linha de base e comparar.

O script abaixo gera um hash de cada arquivo de configuração dos agentes e compara com a execução anterior. Coloque num cron diário ou no login e você vai saber no mesmo dia quando algo mudar.

#!/usr/bin/env bash
# Detecta mudanças nas configurações dos agentes comparando hashes.
# Primeira execução cria a linha de base; as próximas mostram o que mudou.

set -u

base="$HOME/.agent-config-baseline.txt"
atual="$(mktemp)"

# Gera "hash  caminho" para cada arquivo de config relevante
find "$HOME/.codex" "$HOME/.claude" "$HOME/.copilot" \
  -maxdepth 2 -type f \( -name '*.toml' -o -name '*.json' \) 2>/dev/null \
  | sort \
  | xargs -I{} shasum -a 256 "{}" > "$atual"

if [ ! -f "$base" ]; then
  mv "$atual" "$base"
  echo "Linha de base criada em $base"
  exit 0
fi

if diff -u "$base" "$atual"; then
  echo "Nenhuma mudança nas configurações dos agentes."
  rm -f "$atual"
else
  echo "ATENÇÃO: configurações mudaram desde a última verificação."
  echo "Revise as linhas acima e, se estiver tudo certo, atualize a base:"
  echo "  mv $atual $base"
fi

É simples de propósito. Não depende de nenhuma ferramenta extra e mostra exatamente qual arquivo mudou. Quando o diff aparecer, você abre o arquivo e decide.

Uma regra para o time

Se você lidera um time, a regra que eu adotaria é: configuração de agente de código é tão sensível quanto ~/.ssh ou as credenciais da nuvem. Um agente com hook confiável roda código a cada sessão, tem acesso ao repositório e muitas vezes a tokens. Já vimos o que acontece quando chaves de API ficam expostas em ferramentas de desenvolvimento, como no caso do vazamento de chaves no OpenCode Console. O plugin que entra sem pedir é a mesma superfície de ataque, só que pela porta da frente.

O Que o Postman Disse

Até o momento em que escrevo, a resposta atribuída ao Postman e citada na issue fala em deixar o opt-in mais claro, especialmente para usuários antigos, e em revisar o comportamento de aprovação de hooks e de início de sessão. Essa resposta foi colada por um usuário na conversa, não por uma conta verificada da empresa. A imprensa de tecnologia, como o The New Stack, publicou que procurou o Postman sobre as instalações automáticas e o consentimento, sem resposta publicada até agora.

As exigências de quem abriu a issue são razoáveis e servem de régua para qualquer fornecedor:

Parar a instalação automática de plugins e CLI para usuários existentes até haver opt-in explícito.
Remover a autoaprovação de hooks pelo instalador.
Identificar a versão ou a feature flag por trás do auto-existing-upgrade.
Oferecer um caminho completo de remoção, cobrindo configs, confiança de hooks, marketplaces, caches, MCP e CLI.
Limitar as instruções de início de sessão a pedidos explícitos sobre o Postman.

Perspectivas: A Guerra Pelo Contexto do Seu Agente

O episódio do Postman mostra uma mudança de jogo. Durante anos, a briga das ferramentas de desenvolvimento era pela sua barra de favoritos, pela sua IDE, pelo seu terminal. Agora a briga é pelo contexto do seu agente. Quem consegue colocar uma instrução no início de cada sessão influencia qual ferramenta o agente recomenda, qual API ele chama e qual serviço ele sugere assinar.

Os próprios agentes já têm parte da defesa: o Codex exige aprovação para hooks justamente por isso. O problema é que essa defesa vale pouco se outro programa na mesma máquina puder escrever o registro de aprovação. A tendência é os agentes endurecerem esse ponto, assinando ou isolando o registro de confiança, e os sistemas operacionais tratarem a pasta de configuração do agente como área protegida.

Enquanto isso não chega, o trabalho é nosso: saber o que está instalado, ter uma linha de base e desconfiar de qualquer texto que entra no contexto sem que você tenha escrito.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu o caso do Postman instalando plugins no Claude Code, no Codex e no Copilot sem pedir, e como auditar a configuração dos seus agentes, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso