Postman без спроса установил плагины в Claude Code и Codex, пишет пользователь

В трекере postmanlabs/postman-app-support появилось подробное обращение пользователя Postman для macOS (версия приложения 12.33.4). По его словам, после открытия давно не использованного Postman в его кодинг-агентах начались сбои и странности: повторяющиеся предупреждения об аутентификации MCP и то, что Codex снова и снова направлял работу над API через навыки Postman. Расследование показало общепользовательский плагин Postman, хук запуска с инструкцией, удалённое MCP-подключение, плагин для Claude Code и отдельно установленный Postman CLI.

Главное доказательство автор берёт из собственного лога Postman (main.log, строки 11562-11563, метка 2026-10-24T09:34:14.418Z). Там записано, что сервис установки плагинов агентов отработал с источником auto-existing-upgrade и результатом claude-code:installed, codex:installed, а затем процесс autoInstall.plugin.existing-user завершился с исходом installed (пользователь был авторизован, платформа darwin).

В глобальном конфиге Codex (~/.codex/config.toml) появились маркетплейс postman (репозиторий postmanlabs/postman-plugin), включённый плагин postman@postman и запись о доверенном хеше хука. Хук SessionStart срабатывает при startup, clear и compact и выводит файл session-start-context.md, который велит агенту перед любой нетривиальной задачей по проектированию, реализации, мокированию, тестированию, мониторингу, документированию или развёртыванию API (или Postman Flow) загрузить навык postman:api-engineer и следовать ему. Автор считает, что это гораздо шире, чем явная просьба использовать Postman.

Отдельный пункт: по прочтению исходников установщика автор утверждает, что installer/src/hosts/codex.ts после установки плагина вызывает approvePostmanHook, а codex-hooks.ts получает хеш хука через hooks/list и записывает trusted_hash через config/batchWrite; комментарий в коде гласит «Approves only Postman's current hook after installation». При этом автор оговаривается: сама запись о доверии не доказывает, кто именно её создал, и как доказательство конкретного действия пользователя он её не подаёт.

Удалённый MCP (mcp.codex.json указывает на https://mcp.postman.com/mcp) был включён без работающего авторизованного соединения: в логах Codex при старте ошибка «Auth required, when send initialize request». Для Claude Code в ~/.claude/settings.json включён postman@claude-plugins-official, в installed_plugins.json записана версия 2.0.1 (пользовательская область) с временем установки 2026-10-24T09:34:02.610Z, а в ~/.local/bin лежат исполняемый файл Postman и каталог lib с временем изменения, совпадающим с окном установки.

Автор прямо оговаривает границы: отчёт устанавливает нежелательные изменения интеграций и инструкций, но не утверждает утечку данных; последовательность пока не воспроизведена на чистом Mac. Закрытые от публикации приватные пути, посторонние логи, идентификаторы аккаунта и учётные данные исключены. После фиксации доказательств автор удалил локальную установку Postman и интеграции.

От Postman автор просит: считать случай серьёзным инцидентом согласия и границ безопасности, а не вопросом документации; остановить автоматическую установку плагинов агентов и CLI для существующих пользователей до явного согласия; убрать самоодобрение хуков установщиком (решать должен пользователь в самом агенте); назвать релиз или флаг функции и порядок получения согласия за auto-existing-upgrade и перечислить, какие ещё агенты и файлы могут меняться; дать полный путь отката (конфиги агентов, доверие хукам, маркетплейсы, кэши, MCP-подключения, CLI) без повторной установки после удаления; сузить стартовые инструкции до явных запросов про Postman.

В обсуждении под обращением много резких реплик пользователей, сравнивающих поведение Postman с вредоносным ПО. Один комментатор пишет, что спрашивал Postman в Discord и там отнеслись несерьёзно; другой утверждает, что Postman изменил содержимое страницы загрузки (в архиве от 26.10.2026 такого текста нет). Это слова комментаторов, не проверенные факты. Из видимого текста не следует, ответил ли Postman официально. Автор одного из комментариев отдельно протестировал механизм доверия хукам в Codex CLI 0.162.1 и Claude Code 2.1.302 и описал, что запись trusted_hash можно вычислить и записать вручную без участия человека; текст комментария в источнике обрывается.

Ключевые факты

По логу Postman 12.33.4 для macOS (main.log, 2026-10-24) автоустановка с источником auto-existing-upgrade поставила плагины в Claude Code и Codex.
В глобальном конфиге Codex появились маркетплейс Postman, включённый плагин и хук SessionStart, который велит агенту загружать навык postman:api-engineer перед любой нетривиальной работой с API.
По прочтению исходников автор утверждает, что установщик пытается сам одобрить свой хук (approvePostmanHook, запись trusted_hash); кто создал конкретную запись о доверии, автор не доказывает.
Удалённое MCP-подключение к mcp.postman.com при старте Codex падает с ошибкой «Auth required»; рядом установлен Postman CLI в ~/.local/bin.
Автор не утверждает утечку данных и не воспроизвёл ситуацию на чистом Mac; требует остановить автоустановку без согласия и дать полный откат.

Почему это важно

Речь о границе доверия между инструментами разработчика. Если приложение, которое просто открыли, само прописывает себя в конфигурацию других кодинг-агентов, добавляет стартовые инструкции и подключает удалённый MCP-сервер, пользователь теряет контроль над тем, что видят и делают его агенты. Автор обращения формулирует это как серьёзную проблему согласия и границ доверия. Заголовок на Hacker News говорит о попытке поделиться всеми данными API, но сам текст обращения этого не утверждает: там задокументированы нежелательные изменения интеграций и инструкций, а не утечка.

Кому это важно

Пользователям десктопного Postman, особенно на macOS и особенно тем, кто параллельно использует Codex или Claude Code, а также командам, отвечающим за безопасность рабочих станций разработчиков и политики допустимых плагинов. Тем, кто выбирает инструменты для работы с API, поведение вендора по части согласия тоже стоит учесть. Автор просит Postman назвать релиз или флаг функции за auto-existing-upgrade и перечислить, какие ещё агенты и файлы могут меняться; число затронутых пользователей в источнике не указано.

Как это применить

Если вы пользуетесь Postman вместе с кодинг-агентами, проверьте места, где автор нашёл следы: ~/.codex/config.toml (разделы marketplaces.postman, plugins и hooks.state), ~/.claude/settings.json и ~/.claude/plugins/installed_plugins.json, каталог ~/.local/bin (исполняемый файл Postman и lib), а также main.log приложения на записи auto-existing-upgrade. Автор указывает, что нужен полный откат: конфиги агентов, доверие хукам, маркетплейсы, кэши, MCP-подключения и CLI. Официального пути удаления в источнике нет, это одно из требований автора к Postman.

Можно ли доверять

Это отчёт одного пользователя об одной машине, и сам автор честно пишет, что последовательность ещё не воспроизведена на чистом Mac. Сильная сторона: приведены строки лога с временем, версии, фрагменты конфигов и ссылки на исходники плагина, закреплённые на конкретной ревизии. Выводы о самоодобрении хука основаны на чтении исходников; автор прямо говорит, что запись о доверии не доказывает, кто её создал. В видимом тексте нет ответа Postman. Реплики комментаторов (в том числе о правке страницы загрузки) не подтверждены и отражают эмоции, а не факты отчёта.

Риски и подводные камни

Не следует читать обращение как доказательство кражи данных: автор это прямо исключает. Реальные риски, о которых он пишет: стартовая инструкция в хуке заставляет агентов по умолчанию направлять общую работу над API через Postman, а удалённое MCP-подключение и самоодобрение хука расширяют поверхность доверия. Один из комментаторов показал, что запись о доверии хуку в Codex можно вычислить и записать вручную, то есть защита хуков на уровне конфигурации опирается на то, что процессы пользователя не злоупотребляют этим. Текст источника обрывается, поэтому развитие обсуждения и возможная реакция Postman здесь не отражены.

«API-клиент не должен делать себя рабочим процессом по умолчанию в других инструментах только потому, что я его открыл.»

— автор обращения в трекере postmanlabs/postman-app-support