セキュリティ

Postmanが Claude Code・Codex にプラグインを自動導入 — フック自己承認の仕組みと確認すべき4か所

PostmanClaude CodeCodexMCPセキュリティAIエージェント

はじめに

API クライアントの Postman のデスクトップアプリが、ユーザーの操作なしに Claude Code と OpenAI Codex へ自社プラグインをインストールした、という GitHub Issue が Hacker News で話題になっています（執筆時点で 460pt 超）。Issue には、Codex の起動時に動く「フック」をインストーラー自身が信頼済みとして登録した、という指摘も含まれます。

この記事では、Issue に書かれたログと設定ファイルから何が起きたとされているのかを整理します。そのうえで、Postman の公式ドキュメントと照らし合わせて仕組みを説明し、手元の環境で確認すべき場所をまとめます。HN のタイトルは「全 API データを共有しようとする」となっていますが、Issue 自体はそこまで主張していません。この違いにも触れます。

何が報告されたのか

Issue #14370 は 2026 年 10 月 25 日（UTC）に起票されました。執筆時点（11 月 4 日）でも open のままで、ラベルや担当者は付いておらず、Postman 社員のコメントもありません。

報告された環境は macOS の Postman デスクトップ 12.33.4 で、サインイン済みのユーザーです。報告者が示した Postman のログ（~/Library/Application Support/Postman/logs/main.log）には、10 月 24 日 09:34（UTC）に次の記録がありました。

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

auto-existing-upgrade という名前からは、「既存ユーザー向けのアップグレード時の自動インストール」という経路があると読めます。同じログには autoInstall.plugin.existing-user finished という行もあります。

報告者が見つけた変更は次のとおりです。

  • Codex: ~/.codex/config.toml に Postman のマーケットプレイス（postmanlabs/postman-plugin の Git リポジトリ）とプラグイン postman@postman 1.1.0 が追加され、有効化されていた。さらに [hooks.state] に Postman の SessionStart フック用の trusted_hash が書かれていた
  • Claude Code: ~/.claude/settings.json で postman@claude-plugins-official が有効化されていた。~/.claude/plugins/installed_plugins.json には 2.0.1 がユーザースコープで記録されていた
  • リモート MCP: Codex 用の設定が https://mcp.postman.com/mcp を指していた。ただし Codex のログでは、認証が必要なため起動に失敗していた
  • CLI: ~/.local/bin に Postman の実行ファイルが置かれ、更新時刻がインストールの時間帯と一致していた

報告者は注意書きも添えています。

This report establishes unwanted integration and instruction changes; it does not claim to establish data exfiltration.

Issue が立証しようとしているのは「望んでいない統合と指示の変更」です。データの外部送信までは主張していません。報告者はクリーンな Mac での再現もまだ行っていないと明記しています。

技術的な背景：フックの「信頼」をインストーラーが済ませる

この件で一番問題になっているのは、プラグインが入ったことそのものより、Codex がユーザーに求めるはずの確認を、インストーラーが自分で済ませる処理を持っていた点です。ただし報告者は、実際に残っていた信頼記録を誰が書いたかまでは立証できないと明記しています。

Codex では、プラグインに含まれるフックは信頼済みとして登録されるまで動きません。信頼の記録は config.toml の [hooks.state] にハッシュとして保存されます。Postman 公式の手順書には、Codex のアプリやコマンドラインから入れた場合について、次のように書かれています。

The hook installs untrusted. The next time Codex starts, it shows “Hooks need review.”

一方で、npx @postman/postman-plugin で検出したエージェントすべてに入れる経路について、同じドキュメントは「インストーラーがフックを承認する」と説明しています。プラグインの README にも「別途フックの確認画面は出ない」とあります。つまり npx インストーラーがフックを承認するのは、公開されている仕様どおりの動作です。

問題は、その仕様がデスクトップアプリから、ユーザーの操作なしに動いたとされる点です。ユーザーが自分で npx コマンドを打つなら、承認を任せる判断をしたと言えます。しかしアップデートのついでに実行されると、その判断が抜け落ちます。報告者はプラグインのソース（installer/src/hosts/codex-hooks.ts）を読み、approvePostmanHook が hooks/list でハッシュを取得して config/batchWrite で書き込むことを示しています。

承認されたフックの中身も議論になっています。SessionStart フックは、起動・clear・compact のたびに指示文を読み込ませます。その指示文は、API や Postman Flow の設計・実装・モック・テスト・監視・ドキュメント作成・デプロイといった、自明でない「API エンジニアリングの作業」全般で postman:api-engineer スキルを読み込むよう求めています。報告者は「ユーザーが Postman を使うよう明示的に頼んだ場合よりずっと広い」と指摘しています。エージェントへの指示は、ユーザーが知らないうちに作業のやり方を変えてしまいます。

なお、執筆時点の Postman のダウンロードページには「Postman アプリには Postman CLI と Postman プラグインが含まれる」という一文があります。ただし、コーディングエージェントへ自動で導入するという記述はありません。Issue のコメントで「ダウンロードページが後から書き換えられた」という指摘があり、Wayback Machine の 10 月 26 日のスナップショットを見ると、確かにこの一文はありませんでした。追加されたのは自動インストール（10 月 24 日）と Issue 起票より後です。追加した理由はわかりません。

エンジニアへの影響と確認手順

Postman デスクトップを入れている Mac では、次の 4 か所を確認してください。DEV Community の解説記事が挙げている確認先とほぼ同じで、3 番目だけは Issue の記載から加えたものです。

  1. ~/.codex/config.toml — [marketplaces.postman]、postman@postman、[hooks.state] 内の Postman のエントリ
  2. ~/.claude/settings.json — postman@claude-plugins-official が有効になっていないか
  3. ~/.claude/plugins/installed_plugins.json — Postman プラグインの記録と installedAt の日時
  4. ~/.local/bin — 自分で入れた覚えのない Postman CLI

公式ドキュメントにある削除手段は npx @postman/postman-plugin remove です。ただし、これは npx インストーラーで入れた場合の手順です。デスクトップアプリ経由で入ったものに効くかは、公式には説明されていません。Claude Code と Codex それぞれのプラグイン削除手順も、Postman のドキュメントには載っていません。DEV Community の記事は「デスクトップアプリを消してもエージェント側の統合は消えないと考えるべきだ」と注意しています。削除後は、上の 4 か所を目で見て確かめるのが確実です。

この件から、Postman に限らない教訓が 2 つあります。

  • エージェントの設定ファイルは、外部のツールが書き換える前提で見張る: ~/.claude や ~/.codex を dotfiles として Git で管理していれば、差分として気づけます。今回の報告者も、設定ファイルの中身を調べて変更に気づいています
  • 組織では、エージェントの設定をソフトウェア資産として扱う: HN では、医療系の現場でセキュリティチームが Postman の利用許可を取り消したという書き込みがありました。フックと MCP は、エージェントに指示を出し外部と通信する経路です。ブラウザ拡張と同じように棚卸しの対象にする必要があります

まとめ

  • Postman デスクトップ 12.33.4 が、auto-existing-upgrade という経路で Claude Code と Codex にプラグインを入れたとする報告が出ています
  • 核心は、Codex で本来ユーザーが確認するフックの信頼を、インストーラーが自分で登録する処理を持っていた点です。npx インストーラーでは公開された仕様ですが、ユーザーが関与しない自動実行は別問題です
  • データの外部送信は立証されていません。HN のタイトルは Issue より強い表現になっています
  • 確認先は config.toml、settings.json、installed_plugins.json、~/.local/bin の 4 か所です

コーディングエージェントのプラグインやフックが増えるほど、「誰がエージェントに指示を足したか」を追える仕組みが必要になります。Postman の公式回答と、自動インストールの扱いがどうなるかを引き続き見ていく価値があります。

今日のその他のニュース

claude -p の --allowedTools は道具を絞らない

Zenn の検証記事によると、--allowedTools は「確認なしで実行してよい道具」の指定で、使える道具の制限ではありません。settings.json で Bash などを許可していると、それも通ります。道具を絞るには --tools を使い、MCP には --strict-mcp-config などを併用します（検証は Windows 11・2.1.296）。

GitBook のインフラ認証情報が侵害

HN に転載されたサポートからの返信によると、11 月 2 日に攻撃者が GitBook のインフラ認証情報の一部を入手しました。GitBook の CTO も HN で攻撃を認めています。アクセスされた可能性があるのは Git Sync のシークレット、API トークン、サードパーティのトークン、GitBook Assistant への質問内容です。GitBook はトークンとシークレットのローテーションと、MCP サーバーの再認証を求めています。正式な告知と事後報告書はまだ出ていません。

ソース

Back to articles