Plugin do Postman no Codex e Claude Code: verificar e remover

Se encontrar um plugin indesejado do Postman no Codex ou Claude Code, preserve a configuração e desinstale o plugin. Remova também qualquer aprovação salva do hook do Codex. Não autentique uma conexão MCP do Postman que você não escolheu.

Verifique o resultado em uma nova sessão antes de voltar ao trabalho habitual.

O sintoma descrito na issue #14370 do Postman era este:

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

O autor também relatou o carregamento repetido de habilidades do Postman durante tarefas com APIs. Esses sintomas justificam verificar a integração. Eles não comprovam que dados de APIs foram enviados.

O que mudou depois dos primeiros relatos?

Em 2026-11-10, a resposta já incluía um anúncio de reversão e mudanças no plugin do Codex. Não trate o comportamento do instalador original como uma descrição inalterada de todas as instalações atuais.

O relato original tratava do Postman para desktop 12.33.4 no macOS, com o plugin do Codex 1.1.0 e o do Claude Code 2.0.1. Um relato posterior sobre a versão 12.35.1 descreveu outra instalação automática. Porém, esse computador não tinha um registro de confiança do hook do Codex, e o plugin do Cursor já existia.

Em 5 de novembro, preethammavin, membro do repositório, anunciou que o Postman estava revertendo a mudança. Esse comentário difere dos anteriores cujos autores não tinham uma associação de membro no GitHub.

Também em 5 de novembro, o pull request #149 foi integrado e removeu a aprovação feita pelo instalador. Ele também excluiu hooks/codex-hooks.json e definiu "hooks": {} no manifesto do Codex. O manifesto atual do Codex mantém essa declaração vazia de hooks. As habilidades do Postman e um servidor MCP continuam incluídos.

Essas mudanças não comprovam que uma instalação existente foi limpa. Confira os arquivos instalados. Não presuma que uma atualização do aplicativo de desktop removeu registros antigos ou aprovações de confiança.

Verifique o que o Postman gravou antes da remoção

Primeiro, feche o Postman e as sessões ativas dos agentes. Antes de editar, salve cópias privadas da configuração afetada, dos registros de instalação e dos logs relevantes.

Use o diretório raiz de configuração da sessão afetada. O terminal e o aplicativo de desktop podem ter ambientes de inicialização diferentes. A verificação abaixo, para Bash, respeita CODEX_HOME e a variável documentada CLAUDE_CONFIG_DIR do Claude Code.

Ela exibe os nomes dos arquivos com correspondências, não o conteúdo da configuração:

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

Uma correspondência é uma pista para investigar, não uma prova de instalação automática. A ausência de correspondências se limita a esses arquivos.

Para a instalação relatada no macOS, examine ~/Library/Application Support/Postman/logs/main.log. A issue incluía este resultado de instalação:

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

Compare o horário dessa entrada com os registros de instalação dos plugins. Uma sequência de horários compatível oferece evidência mais forte do que encontrar a palavra “Postman” em um arquivo de configuração.

No Codex, examine estas três entradas separadas do relato original:

Entrada de configuração	O que verificar
[marketplaces.postman]	Se a origem é https://github.com/postmanlabs/postman-plugin.git.
[plugins."postman@postman"]	Se o plugin está habilitado.
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]	Se uma aprovação salva contém trusted_hash, trusted_content_hash ou ambos.

A ausência de uma entrada de confiança não descarta a instalação do plugin. O relato posterior mostrou essa diferença.

No Claude Code, confira enabledPlugins em ~/.claude/settings.json. O identificador relatado era postman@claude-plugins-official. Em ~/.claude/plugins/installed_plugins.json, examine o escopo, a versão, installedAt e lastUpdated da instalação correspondente.

Para o Cursor, o adaptador do instalador identifica dois locais:

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

Use esses locais como pontos de partida para a investigação. Confirme se o plugin está habilitado nas configurações do Cursor, em vez de deduzir isso apenas pela existência de um diretório.

Mantenha os arquivos completos de configuração e os logs privados. Eles podem conter credenciais, caminhos internos ou informações de contas. Compartilhe apenas as entradas relevantes, depois de ocultar os dados sensíveis.

Remova o plugin e a aprovação salva separadamente

Escolha entre os comandos nativos do agente e a ferramenta de remoção do Postman. Não execute todas as opções automaticamente.

Use os comandos nativos para uma remoção específica

Para o identificador do plugin do Codex citado no relato, execute isto no Bash:

codex plugin remove postman@postman

Depois, remova o marketplace somente após confirmar sua origem e verificar se nenhum plugin necessário ainda o utiliza:

codex plugin marketplace remove postman

Essas operações correspondem ao adaptador atual do Postman para Codex. Se uma instalação antiga tiver outro registro, use os identificadores que realmente existem no seu computador.

Para a instalação do Claude Code no escopo de usuário descrita no relato:

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

A referência de comandos de plugins do Claude Code diferencia os escopos user, project e local. Se confirmar uma instalação no escopo de projeto ou local, use o escopo correspondente a partir desse projeto. Combine com a equipe a remoção de configurações compartilhadas do projeto.

Não remova todo o marketplace claude-plugins-official para excluir um único plugin. Não esvazie installed_plugins.json nem substitua o arquivo inteiro de configurações.

Se a CLI instalada rejeitar um comando, consulte seu plugin --help antes de continuar. Não substitua um comando de desinstalação incompatível pela exclusão indiscriminada de diretórios.

Alternativa: use a ferramenta de remoção documentada pelo Postman

As instruções atuais do repositório do Postman fornecem este comando de remoção:

npx @postman/postman-plugin@latest remove

Use essa opção somente depois de revisar e aprovar o código do pacote e conferir quais agentes serão afetados. O código atual do instalador exige Node.js 22 ou posterior. Mantenha o subcomando remove: executar o instalador sem ele não realiza uma limpeza.

A ferramenta documentada mantém as instalações no escopo de projeto. Sua implementação atual para Codex também tenta revogar a aprovação do antigo hook de inicialização.

Essa última operação precisa ser verificada separadamente. A implementação da revogação pode informar um problema de limpeza sem fazer a remoção inteira falhar. Leia os avisos e examine o arquivo depois.

Exclua qualquer aprovação do Codex que ainda exista

Se a subseção abaixo permanecer na configuração de usuário do Codex afetada, remova-a por completo:

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

Esse bloco identifica a seção que deve ser removida. Não é uma configuração para adicionar.

Exclua juntos os campos trusted_hash e trusted_content_hash dessa seção. Pare antes do próximo cabeçalho de tabela TOML. Preserve as outras entradas de hooks.state.

Ao editar manualmente, remova apenas entradas que comprovadamente pertencem ao Postman. Preserve model_provider, model_providers, base_url, os ajustes de autenticação e os hooks não relacionados. No Claude Code, preserve os ajustes de env e de permissões que não tenham relação com o Postman.

Após a remoção nativa, confirme que os registros correspondentes do plugin e do marketplace desapareceram. Em qualquer uma das opções, verifique se a aprovação salva do Postman também foi removida. Uma mensagem de desinstalação, sozinha, não comprova as três condições.

Confira o Cursor, as entradas MCP separadas e a CLI

Instalações do marketplace do Cursor exigem uma ação adicional: desinstale o Postman em Cursor Settings > Plugins e reinicie o Cursor. Após qualquer opção de remoção, confira a lista de plugins do Cursor para localizar instalações restantes do Postman.

Se um aviso de MCP continuar aparecendo, examine a configuração do servidor em vez de fazer login para silenciá-lo. No Bash, use o comando correspondente a cada agente afetado:

codex mcp list
claude mcp list

Um servidor configurado separadamente também precisa ser removido separadamente. Confirme que a entrada independente indesejada se chama postman. Depois, use codex mcp remove postman ou claude mcp remove postman. Confira o escopo da entrada antes da remoção. A referência do Codex CLI e a documentação de MCP do Claude Code descrevem esses comandos.

Não confunda um servidor independente com um servidor fornecido por um plugin habilitado. Para uma conexão fornecida por um plugin, remova o plugin responsável por ela.

Confira a CLI do Postman separadamente. No Bash, type -a postman mostra os comandos correspondentes encontrados no seu caminho de busca. No incidente original, o executável estava em ~/.local/bin; não presuma que todas as instalações usam esse local.

Siga as instruções de desinstalação da CLI conforme o método de instalação. Para uma instalação que não foi feita com npm, o método documentado remove o executável. Examine os arquivos que o acompanham antes de excluí-los. Nunca apague um diretório lib compartilhado só porque o relato mencionou um.

Verifique a limpeza em uma nova sessão

Verifique a configuração e os componentes carregados, não apenas a ausência de um aviso.

Primeiro, consulte os inventários de plugins dos agentes afetados:

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

Procure todos os registros do Postman, incluindo instalações com outro sufixo de marketplace ou escopo. Confirme que a subseção exata de aprovação do hook do Postman não aparece na configuração ativa do Codex.

Inicie uma nova sessão do agente em uma cópia de trabalho descartável do repositório. Confira se nenhum plugin ou conexão MCP indesejado do Postman é carregado. A integração removida não deve gerar um novo aviso de autenticação do Postman.

Não use as referências ao Postman em uma conversa antiga como única verificação. O texto da conversa e a configuração instalada são coisas diferentes. Por isso, importa a diferença entre iniciar uma nova sessão do Claude Code e compactar uma sessão existente.

Se o Postman ainda aparecer, confira o diretório de configuração, o escopo de instalação, os registros restantes de plugins e as entradas MCP separadas. Não exclua repetidamente o mesmo arquivo padrão sem localizar a origem ativa.

Se mantiver o Postman para desktop, compare a configuração novamente após sua próxima inicialização ou atualização controlada. Se as entradas voltarem, preserve os novos horários dos logs e as diferenças de configuração. Pause a distribuição desse aplicativo de desktop enquanto investiga qual processo recriou as entradas.

Por que o instalador conseguia gravar a confiança de um hook do Codex?

O instalador antigo usava a interface de configuração do Codex para salvar uma aprovação. Ele não se limitava a registrar o plugin e deixar a decisão de confiança para a revisão interativa.

No commit 6c8e452e0f4237f4bcc0901cb1ac442dec707e49, o registro do hook usava SessionStart com o matcher startup|clear|compact. Seu texto de instruções direcionava tarefas não triviais de engenharia de APIs para postman:api-engineer.

Essa instrução abrangia mais do que pedidos explícitos para usar o Postman. Ela dispensava perguntas sem ações e edições triviais, além de dar prioridade às instruções do usuário.

A implementação antiga de approvePostmanHook iniciava codex app-server. Ela obtinha o hash atual do hook por hooks/list, fazia a verificação e chamava config/batchWrite. Essa gravação inseria trusted_hash em hooks.state.

Isso comprova uma tentativa de aprovação. Não comprova sucesso em todas as versões do Codex nem identifica quem criou o registro existente em um computador específico.

O mecanismo de confiança documentado do Codex compara o hook com seu hash salvo. Hooks novos ou alterados não são executados enquanto aguardam revisão e aprovação. Portanto, o limite importante é o acesso ao estado de aprovação. Um hash correspondente, sozinho, não comprova que uma pessoa aprovou o hook.

A implicação prática é local: um programa com acesso suficiente à configuração do agente pode alterar ajustes relevantes para a segurança. Habilitação do plugin, confiança do hook e autenticação MCP remota são controles separados. Remover apenas um deles pode deixar os demais configurados.

Evite novas alterações nos computadores da equipe

Mantenha uma configuração de referência aprovada e sem dados sensíveis. Compare-a após instalações e atualizações de ferramentas. Guarde modelos e alterações revisadas no controle de versão, não credenciais ativas nem diretórios completos de configuração pessoal.

As diferenças entre arquivos detectam mudanças, mas não impedem que um processo da mesma conta grave nesses arquivos. Para impor restrições, use políticas controladas por administradores que aplicativos comuns de desktop não possam reescrever.

No macOS ou Linux, o arquivo de requisitos do sistema do Codex é /etc/codex/requirements.toml. Incorpore este ajuste no nível superior do arquivo existente:

allow_managed_hooks_only = true

A documentação de configuração gerenciada descreve os locais de implantação. A referência de configuração define esse ajuste: ele ignora hooks de usuário, projeto, sessão e plugins, mas permite hooks gerenciados.

Para o Claude Code no macOS, incorpore o seguinte em /Library/Application Support/ClaudeCode/managed-settings.json:

{
  "allowManagedHooksOnly": true
}

Esse é um ajuste de política gerenciada, não um substituto para editar preferências do usuário. Os controles de hooks do Claude Code bloqueiam hooks de usuário, projeto e outros plugins. A referência de ajustes mantém exceções importantes: hooks gerenciados, hooks do SDK e hooks de plugins habilitados obrigatoriamente por enabledPlugins nas configurações gerenciadas.

Teste as políticas nas versões dos clientes realmente usadas pela equipe antes de uma implantação ampla. Restrições de hooks não desinstalam plugins nem removem conexões MCP; controle esses componentes separadamente.

Estenda a revisão aos arquivos de instruções baixados e aos ajustes do provedor. A auditoria de configuração do Codex e Claude Code oferece uma lista mais ampla para identificar mudanças sem descartar uma configuração de modelo que funciona.