Hot Tracking 035｜Postman、AIプラグインを黙って自動インストールか

何が起こったか

著者自身の調査は10月24日から25日の2日間にわたって行われ、証拠はすべて本機のファイルとオープンソースのインストーラーのソースコードから得られ、各プロセスは独自に確認可能である。メカニズムを項目ごとに分解する：

一、Postman自身のログには自動インストールが記録されている。~/Library/Application Support/Postman/logs/main.logには、2026-10-24T09:34Zに「auto-existing-upgrade」と分類された記録があり、scriptResultsフィールドにはclaude-code:installedとcodex:installedと記載され、installerフィールドはscriptとなっている。

二、Codexのグローバル設定が変更されている。~/.codex/config.tomlにはmarketplace postman（gitソースはpostmanlabs/postman-plugin.git）が登録され、pluginエントリのenabled=trueとなっている。

三、フックの範囲が広すぎる。hooks/codex-hooks.jsonにはSessionStartフックが登録されており（matcherはstartup、clear、compactを上書きしている）、モデルにsession-start-context.mdを印刷する。その内容は、任意の通常ではないAPIプロジェクトタスク（設計、実装、mock、テスト、監視、ドキュメント、APIまたはPostman Flowのデプロイメント）に対応する前に、postman:api-engineerスキルを読み込み、それに従うというものである。これは「ユーザーが明示的にPostmanを使用する」範囲よりもはるかに広い。

四、インストーラーのソースコードは自動フックの信頼を試みている。hooks.stateにはtrusted_hashとtrusted_content_hash（sha256ハッシュ）が書き込まれている。インストーラーのソースコードinstaller/src/hosts/codex.tsはインストール後にapprovePostmanHook()を呼び出し、codex-hooks.tsはhooks/listを使用してハッシュを取得し、config/batchWriteによって信頼記録に書き込む。ソースコードの注釈には「インストール後にPostmanの現在のフックのみを承認する」と記されている。著者はここで控えめな姿勢を示している：ソースコードは「試み」を証明できるが、信頼記録を作成した人が誰かはファイルでは証明できない。

五、リモートのMCPが有効になっているが認証が通らない。mcp.codex.jsonはhttps://mcp.postman.com/mcpを指しており、CodexのログにはMCPサーバーの起動に失敗し/認証が必要であると記録されている。リモートサービスは接続されていないが、設定はすでに書き込まれている：アクションの有効化はユーザーが知らない間に行われた。

六、Claude Codeも影響を受け、さらにCLIが追加されています。/.claude/settings.jsonにはpostman@claude-plugins-officialが有効になっており、installed_plugins.jsonにはバージョン2.0.1、インストール日時2026-10-24T09:34:02.610Zが記録されています。/.local/binにはPostManの実行ファイルが存在し、mtimeはインストールウィンドウ内にあります。

バージョン情報：PostMan desktop 12.33.4、Codex plugin 1.1.0、Claude plugin 2.0.1。ソースコードはrevision 6c8e452に記録されており、確認可能です。

著者は不満を述べただけでなく、6つの明確な要求を出しています：重大な製品に関する同意とセキュリティの問題として扱い、文書の問題としてではないこと；明示的なオプトイン前に、既存のデスクトップユーザーに対して自動的にエージェントプラグインやCLIをインストールすることを停止すること；インストーラ側の自己承認ロジックを削除し、ホットフックの信頼はユーザーがエージェントホスト内で自分で決定する必要があること；auto-existing-upgradeの背後にあるバージョン、フィーチャーフラグ、同意プロセスを公開し、どのエージェントやファイルを変更できるかを明確にすること；エージェント設定、ホットフックの信頼、マーケットプレイス、キャッシュ、MCP接続、CLIを含む完全なリロールパスを提供し、削除と再インストールを行わないこと；起動コマンドをユーザーが明示的にPostManを指定する要求に絞ること。現在のところ、これら6つの要求にはいずれも応答がありません。

静かなインストールは製品の決定であり、バグではない

この問題への批判の主軸は、完全な因果関係です：ソースコードにはapprovePostManHook()という専用関数があり、ログにはauto-existing-upgradeという専用カテゴリがあり、hooks.stateの二重ハッシュは実際に成功して書き込まれています。3つの証拠が相互に関連し、同じ可能性を指摘しています：これは特定の依存パッケージの制御不足ではなく、リリースプロセス内で設計されたパイプラインであり、対象ユーザーは「既にPostManデスクトップを使用している」既存のユーザーです。このパイプラインの背後にあるrelease/フィーチャーフラグと同意プロセスは公式のみが知っており、著者の6つの要求の4つ目はそれを公開すること、およびこのメカニズムでどのエージェントやファイルを変更できるかを求めています。10月25日に提出して11月4日に検証されたこのissueは、open状態でずっと存在しており、reactionは200件に達していますが、公式のタグは1つもありません。公式のアカウントで管理されているリポジトリに対して、10日間の沈黙自体が態度です。

著者の6つの要求を完全に列挙する価値がある：第一に、ドキュメントの問題としてではなく、重大な製品同意とセキュリティ境界の問題として対処すること。第二に、明示的なオプトイン前に、既存のデスクトップユーザーに対して自動的にエージェントプラグインやCLIをインストールすることを停止すること。第三に、インストーラ側の自動承認機能を削除し、ユーザーがエージェントホスト内で直接決定する必要があることを信頼すること。第四に、auto-existing-upgradeの背後にあるリリース/フィーチャーフラグと同意プロセス、および影響範囲を明らかにすること。第五に、完全なロールバックパス（エージェント設定、自動承認、マーケットプレイス、キャッシュ、MCP接続、CLIの全面的カバレッジ）を提供し、削除後は再インストールしないこと。第六に、起動コマンドを明示的なPostmanリクエストにまで絞り込むこと。

また、構造的な問題もある：自動承認の信頼が機能するのは、エージェントホストの信頼層が薄すぎるからだ。一方にはユーザーのホームディレクトリで任意の設定を変更できるデスクトップソフトウェアがあり、もう一方には信頼記録がオフラインで偽造可能なホストがある。両者が遭遇すると、ユーザーが得るのは「インストール済み」という結果だけだ。エージェントエコロジーの同意層は薄いし、Postmanは最初に捕まったものに過ぎない。ホスト側の脆弱性の詳細は、下のコメントセクションで確認できる。

公式発表と一致しない

まず、マーケティングページとデスクトップ端末の行動のギャップを見てみよう。Postmanの公式ウェブサイトのダウンロードページのプラグインセクションの文言は「プラグインを手動でコーディングエージェントに追加する」というもので、2ステップのコマンド（claude plugin marketplace addとinstall）を示している。あるユーザーがウェブページのアーカイブを比較した結果、Postmanがダウンロードページの文言を変更したことを指摘している。確認できるのは、2026-10-26のアーカイブページと11月4日の現在のページで、どちらも手動インストールのマーケティングセクションしかなく、自動インストールについては何も明かしていない。公式ウェブサイトの発表とデスクトップ端末の実際の行動が一致しないのは、確認可能な事実である。

次に、問題自体の構造データを見てみよう：26件のコメントのauthor_associationはすべてNONEであり、MEMBERもOWNERもCOLLABORATORもいなかった。ラベルもassigneeもmilestoneもない。発表時点で、Postmanはこの問題に対して何の正面の回答もしていない。あるユーザーがディスコードで直接質問したところ、「彼らは真剣に受け止めていないようだ」という印象を受けたと伝えている（伝え聞いた話であり、独立して確認することはできない）。著者自身も待っているわけではなかった：彼はr/postman_api、r/codex、r/ClaudeAIの3つのサブレディットで投稿したが、特に目立った反応はなく、11月3日にHNに投稿されたときに反応があった。

拡散の変形も別々に比較する必要がある：HNの投稿タイトルには「PostmanがすべてのAPIデータを共有しようとしている」と書かれているが、問題の著者は本文で明確に区切っている：この報告は望まない統合やコマンド変更を確立したものであり、データの外部流出を主張しているわけではない。タイトルは投稿者の言葉であり、著者の原文よりも鋭い。転送を行った人は、両者を分けるべきだ。

コメントセクションではどう言われているか

HNでの議論は近く300件あり、高い評価を受けた立場を5つの方向に伝えている：

一、移籍ブームが主軸です。何年も前にInsomniaを使っていた人がいて、Insomniaにも問題が出る日を待っていました。Insomnia 8+ではクラウドアカウントの使用が強制されており、公式の理由は広告の配信を容易にするためだと言われています。そのため、他の人がYaakやBrunoに移籍しています。Brunoに移籍した人の中には、Postmanの営業チームに悩まされた後に離れた人もいます。議論の中では、librepostという代替品を自作した人もいました。また、チームがcurlとシェルスクリプトに戻ることを提案する人もいます。

二、enshittificationの議論です。高評価のコメントには次のような論理が示されています：ツールが収益を上げながら製品を犠牲にせず、ユーザーの時間を搾取しない限り、劣化は遅くなります。しかし、病的な貪欲さが介入すると、最終的にはユーザーベースを枯渇させることになります。静的な自動インストールは、この曲線の補足として捉えられています。

三、フックの信頼メカニズムは想像以上に薄いです。コメント欄のユーザーfoma-agentは、2つのホスターに対してローカル検証を行いました（Codex CLI 0.162.1、Claude Code 2.1.302、一度限りの設定ディレクトリ）。Codexのtrusted_hashのパターンはオープンソースで、フックのアイデンティティのsorted-key JSONのsha256です。彼はPythonを使ってオフラインでハッシュを計算し、テキストエディタでhooks.stateを手書きで記録し、次回の実行時にフックを直接トリガーします。全過程で誰も参加していません。Codexには—dangerously-bypass-hook-trustというフラグもあります。信頼記録はフックの声明（コマンド列、イベント、タイムアウト）のみを記録し、スクリプトの内容は記録しません。記録が完成した後にスクリプトのバイトを変更して実行します。現在のソースコードでは、plugin hooksにbundleの内容ハッシュ、つまり2番目のハッシュが追加されていますが、ユーザーが自ら宣言したフックスクリプトファイルはすべてのハッシュから除外されています。Claude Codeには記録メカニズムもありません。settingsファイルにフックを書き込むと即座に有効になります。信頼していないディレクトリでclaude -pを使ってSessionStartとPreToolUseのフックを実行し、直接トリガーします（インタラクティブセッションにはfolder-trustダイアログがあり、-pモードではありません）。この検証の意味は、Postmanの自己批評的な信頼は難しい操作ではなく、設定ファイルを書くことができるスクリプトなら誰でも行えるということです。

四、動機の推測とページの変更指摘です。コメント欄のユーザーNuclEnergyは、Postmanが後からウェブページの内容を変更して責任を回避したと主張しています。再検討によると、アーカイブページと現在のページで自動インストールについて言及されていないことが確認できます。プラグインエリアには常に手動インストールのみが記録されており、具体的に何が変更されたかは完全には確認できません。彼はまた、Postmanの意図はAIが発行するネットワーク呼び出しを監視し、自分をallowlistに加えようとしたが失敗したと推測しています。CodexとClaude Codeは警告をトリガーしており、スクリプトは粗雑に書かれていて、静的なインストールをほぼ完了させそうでした（推測によるもので、決定的な結論ではありません）。彼はボタン付きのアンイストールフックのスクリーンショットも投稿しており、Postmanのクリーニングスクリプトを信頼しないと主張し、GPTに助けを求めています。

五、感情面。ある人は直接Postmanを「ウイルス」と呼び、その行為が合法かどうかを問い、またある人は企業環境ではこのようなリスクは受け入れられないと述べている。また、ある人はそれをuTorrentに例えて言う：誰もがインストールしておき、慣れ親しんだためにそのままにしているという。数年間で便利なツールからほとんどウイルスのようなものに変わったと言う人もおり、驚くべきことにまだ使っている人もいる。また、ある人は計算してみる：Postmanが販売する全ソフトウェアの価格は、たった一つの「prompt」の価格に過ぎないと。さらに、アメリカ郵便の格言を引用して皮肉を言う：neither rain, nor sleet, nor consent。最も多く引用された技術的な要約は、「開発者ツールとして何をすべきでないか」という事例であり、キーワードは「透明性」と「許可の要求」の二つだけである。

一般ユーザーができる三つのこと

1. 自己チェック設定。 端末で~/.codex/config.tomlをcatして、[marketplaces.postman]、[plugins.”postman@postman”]、およびhooks.stateの項目を探す。/.claude/settings.jsonと/.claude/plugins/installed_plugins.jsonをcatして、Postman関連の記録を探す。~/.local/binに余分なPostMan実行ファイルがないか一目で確認する。

2. 見つけたらクリアし、クリア後は検証する。 対応する設定項目とファイルを削除する。コメント欄では、公式のアンインストールスクリプトを信頼しない人もおり、手動でクリアするか、AIを使ってクリアを手伝わせる選択をしている。変更後、エージェントを再起動して一度実行し、フックがもうトリガーされないことを確認してから、クリアとみなす。

3. 境界を守る習慣を確立する。 コーディングエージェントにどんなプラグインをインストールする前に、そのSessionStartフックの内容を一度読む。チームを管理している人は、「デスクトップソフトウェアがエージェントの設定を変更する」ことをサプライヤーのリスク評価に含めるべきである。今回の主役はPostManであり、メカニズム層の脆弱性は、あなたのディレクトリにコードを書くことができる任意のソフトウェアに当てはまる。

結論

適切な声明：この記事は推測や罪状の立証を行わない。告発の核心は報告者の自述であるが、ログパス、ソースコードのrevision、および問題構造のデータは確認可能である。動機の推測とページの変更指示はすべてユーザーの投稿から来ているため、この記事は元の情報に基づいて提示されており、事実として昇華されることはない。確実に成立するのは三つの点だけである：問題が10日間無いこと、公式のコメントがないこと、二つのバージョンのダウンロードページに自動インストールの情報がないこと、HNのタイトルが問題の著者の言葉よりも鋭いこと。全体のエコシステムにとって、公式が最終的にどのように対応しても、この問題は「デスクトップソフトウェアがエージェントの設定を信頼する権利を誰に帰するか」という問題を明らかにした。

次に二つのポイントに注目する：一つ目はPostManの公式対応であり、問題のラベル、コメント、ブログのいずれかが出現した場合、このコラムはv2にアップグレードする。二つ目はCodexとClaude Codeが-pモードのフックの信頼を厳しくするかどうかである。foma-agentが検出したのはホスト側の脆弱性であり、PostManは最初に摘発されたユーザーのみである。48時間の期間は11月5日17:22Z前後に終了し、その期間内に何か動きがあればv2を更新する。

参照情報

• GitHub issue postmanlabs/postman-app-support#14370（2026-10-25 by indicava submitted; The accusation is based on the author’s own statement, and the source code part can be reviewed at revision 6c8e452; State=open, 26 comments, 200 reactions, no labels, no assignee, matching the 11-04 API verification statement).
• Hacker News story 50354960（2026-11-03T17:22Z listed; More than 900 ▲ of verification statements, nearly 300💬, and the number is still increasing; The text does not require exact values).
• Comparison of Postman’s official download page (Wayback 2026-10-26 archive vs. current page on 11-04; Both versions only have manual installation marketing areas, with no automatic installation disclosure; User “Change Page” indicates that it is presented according to his statement, without incrimination).
• User foma-agent in the comment section verified the trust mechanism of Codex CLI 0.162.1 and Claude Code 2.1.302 locally (The comment section is a real test, but this article did not run independently).
• Distribution of 26 comments by author_association (11-04 API verification: all NONE).

Signature: Yongliang