Postman のデスクトップアプリを開いただけで、Codex や Claude Code 側の設定が書き換わった――そんな報告が GitHub に上がり、かなり強い反応を集めています。単なるバグ報告というより、「外部ツールの振る舞いを、別アプリがいつの間にか変えてよいのか」という境界線の話になっているのが厄介です。しかも問題の中心には、プラグインの自動導入だけでなく、自分で入れたはずのない startup hook を信頼済みにしてしまう仕組みまで含まれています。API クライアントとして便利さを売る製品が、どこまで自律的に動いてよいのか。その線引きが問われています。
元記事の投稿者は、Mac で既存の Postman Desktop を開いたあと、使っている coding agent の挙動が急に変わったと訴えています。Codex では Postman 由来の skill が繰り返し持ち出され、MCP の認証警告も出るようになった。調べてみると、ユーザー全体の設定に Postman の plugin が入り、startup 時に動く hook まで追加され、さらに remote MCP connection と Claude Code 用の plugin、Postman CLI まで別途入っていたというのです。
投稿者が示したログでは、Postman 側の main.log に「auto-existing-upgrade」「claude-code:installed」「codex:installed」と記録されていました。つまり、既存ユーザー向けの更新処理の中で、Codex と Claude Code の plugin が自動的に導入されたと読めます。しかも対象の Postman は 12.33.4、Codex 側の Postman plugin は 1.1.0 だとしています。投稿者はこの時点を 2026年10月24日、調査日を 2026年10月25日と書いています。
さらに問題視されているのが、インストーラが自分自身の hook を信頼済みにしようとしている点です。記事では、install 処理の中で approvePostmanHook(system) が呼ばれ、hooks/list で取得した hash を使って hooks.state に trusted_hash を書き込む流れがあると説明されています。hook の内容自体には、「非自明な API engineering task の前には Postman の api-engineer skill を読み込め」といった広い指示が含まれていて、単に Postman を使うと明示した場合だけでなく、API の設計、実装、テスト、監視、文書化、デプロイまで広く Postman 側へ誘導する文面だったと投稿者は指摘します。
加えて、remote MCP は https://mcp.postman.com/mcp を向いているのに、Codex のログには「Auth required」と出ており、認証できない状態で有効化だけされていたようです。Claude Code の側でも postman@claude-plugins-official が有効になっていたとされ、~/.local/bin に Postman の実行ファイルとライブラリが入っていた痕跡も示されています。投稿者は、これはデータ流出の証明ではないと断りつつ、少なくとも「望まない統合」と「指示の書き換え」は起きたと主張しています。
この件でまず引っかかるのは、問題が「プラグインを入れた」だけでは終わっていないことです。もし単なる拡張機能の提案なら、まだ話は分かりやすい。ところが報告では、Postman が他のツールの設定にまで手を伸ばし、しかもその hook を信頼済みにするところまで自動化していた。ここがいちばん重いと思います。ユーザーにとっては、あるアプリを起動しただけで別のアプリの意思決定ルールが変わるわけで、体験としても不気味ですし、管理上も追いかけにくい。
とくに「API client だから API 関連の作業に出てくるのは自然」という発想は危ういです。便利さの延長であれば、せいぜい関連機能の案内にとどめるべきで、他社製 agent の初期動作に割り込むのは別問題です。元記事の投稿者が “consent and trust-boundary problem” と呼んでいるのはその通りで、同意の粒度が荒すぎる。アプリ単位の同意では足りず、agent host ごとに明示的な opt-in が必要だという主張には、かなり筋があると思います。
もう一つ気になったのは、Postman 側のログにあった auto-existing-upgrade という表現です。言葉だけ見れば、既存ユーザー向けの改善や移行に見えます。ですが実際に起きたことは、Codex、Claude Code、MCP、CLI、hook trust まで含む複数の層にまたがる変更でした。ここで問題なのは、更新の名前が穏やかでも、実際の影響はかなり深いという点です。ユーザーは「アプリが更新された」くらいに受け止めがちですが、裏では別ツールの設定や初期挙動まで変わっているかもしれない。
この手の変更は、社内のセキュリティレビューや監査の観点でも厄介です。とくに enterprise 環境では、ある開発支援ツールが勝手に別の agent の設定を触ると、管理の前提が崩れます。問題の本質は、技術的な巧拙より、どの範囲まで自動化してよいと判断したのかにあるのではないでしょうか。便利さのための自動処理が、いつの間にか「ユーザーが自分で選ぶべき領域」を侵してしまう。そこを曖昧にしたまま進めると、後から「想定内でした」では済まなくなると思います。
元記事で特に引っかかるのは、インストーラが自分の hook を approve する流れです。もし投稿内容どおりなら、これはかなりまずい設計です。もちろん、すべての自動承認が悪いわけではありません。たとえば、ユーザーが明示的に「この製品のこの機能を使う」と選び、その範囲内で必要な初期化をするなら、実用上はあり得ます。ただ、今回のように agent の起動時に広い指示を差し込み、その信頼まで同じ製品側が面倒を見るとなると、検証者と当事者が同じになってしまう。
この構図は、ソフトウェアの世界では昔から警戒されてきたものです。自分で自分を証明する仕組みは、見た目の整合性があっても、第三者からは信用しにくい。今回の報告でも、投稿者は「trust record だけでは誰が作成したか証明できない」と慎重に書いています。そこに誠実さは感じますし、だからこそなおさら、製品側が自動で信頼を埋め込む設計は避けるべきだったと思います。少なくとも hook の信頼は、agent host 側でユーザーが確認して決めるべきで、インストーラが先回りしてしまうべきではありません。
この件は、単純な脆弱性報告として片づけにくいです。データを盗んだ証拠は示されていないし、投稿者もそこまでは主張していません。それでも問題視されるのは、開発者の作業環境の前提を変えてしまうからです。普段使っている toolchain が、ある日から別の製品の都合で動き始めたら、たとえ機能としては正しく見えても、心理的にはかなり強い不信を招きます。
しかも React の数を見る限り、受け止めた人の多くも「不快」や「危険」という感情をそのままぶつけています。これは煽りではなく、開発ツールに求められる信頼の水準が高いからでしょう。コードを書いている最中に使う道具は、便利さだけでは買えません。設定を静かに変え、他の agent にまで影響し、しかも自分の hook を自分で承認するような振る舞いは、たとえ意図が善良でも歓迎されにくいはずです。Postman のような広く使われる製品ほど、その一歩手前で止まる慎重さが必要だったのではないかと思います。
