Postman が Claude Code・Codex 向けプラグインを自動導入——確認・削除・代替【2026年11月】
Postman デスクトップが既存ユーザーに Claude Code・Codex 向けプラグインと CLI を自動導入したと GitHub issue で報告された。流出の証拠はない。確認コマンド、削除手順、組織の対策、代替ツール比較、確認済みの事実と未確認の主張の違いを整理する。2026年11月4日時点。
Postman のデスクトップアプリが、既存ユーザーの環境に Claude Code・Codex などコーディングエージェント向けの Postman プラグインと Postman CLI を、利用者の操作なしに導入していた——という報告が GitHub の issue(#14370)に上がっている。ログ上の導入元は auto-existing-upgrade で、複数のユーザーが同様の痕跡を確認している。データが外部へ送られたことを示す証拠は、報告者自身も「示していない」としている。自分の環境にエントリが残っていないか、まず下記のコマンドで確認してほしい。
この件は 2026年10月25日に起票され、11月3日から4日にかけて Hacker News などで話題になった。本稿は issue とコメントを一次情報に、11月4日時点の確認済みの事実と未確認の主張を分けて整理する。Postman 側の正式な修正リリースや公式の削除手順は、この時点では確認できていない。目的は製品の批判ではなく、「同意なくエージェントの設定が変わる」構造の整理である。
何が起きたか
issue の報告者(indicava 氏)は、macOS 上の Postman デスクトップ 12.33.4 で、Codex 用 Postman プラグイン 1.1.0 と Claude Code 用プラグイン 2.0.1 が、自分で入れた覚えのないまま導入されていたことを発見した。Postman のログ(~/Library/Application Support/Postman/logs/main.log)には、2026年10月24日 09:34 UTC に次の趣旨の記録があったという。
- "source":"auto-existing-upgrade"(既存ユーザーのアップグレード時の自動導入という意味に読める名前)
- "results":["claude-code:installed","codex:installed"]
- "installer":"script"、"signedIn":true
別のユーザー(ronthedrummer 氏)は、11月3日に Postman デスクトップを 12.31.3 から 12.35.1 へ更新した際、同じ auto-existing-upgrade のログが出て、Claude Code と Codex に導入され、Cursor は導入済み(already-installed)と記録されたと報告している。あわせて ~/.local/bin/postman に Postman CLI(バージョン 1.85.0)が現れたという。2人の環境で同種のログが出ている点は信頼性の材料だが、どちらも個人の報告で、Postman 公式の説明ではない。
確認された事実と、未確認の主張
「全 API データを共有しようとする」といった強い言い回しも出回っているため、issue の内容を確認の度合いごとに分ける。
| 内容 | 状況 |
|---|---|
| 既存ユーザーに対し、更新時にプラグインが自動導入された | 2人の報告者がログの抜粋を提示(12.33.4 と 12.35.1)。報告としては整合している |
| Claude Code の設定でプラグインが有効化された | ~/.claude/settings.json に postman@claude-plugins-official が有効化、installed_plugins.json にバージョン 2.0.1 が記録されたと報告 |
| Codex の設定にマーケットプレイスとプラグインが追加された | ~/.codex/config.toml に [marketplaces.postman] と [plugins."postman@postman"](enabled = true)が追加されたと報告 |
| セッション開始時の指示注入 | プラグインのフックが「重要な API エンジニアリング作業の前に Postman のスキルを読み込め」という趣旨の文を出力する、と報告者がソースから説明。Cursor のセッションで同じ文が出たという別報告もあるが、1人の観測で、Codex での実動作は未確認(報告者本人が11月4日に訂正) |
| インストーラーが自分のフックを自己承認した | 報告者はソースコードにその処理(承認の試み)があると説明。ただし「信頼記録を誰が作ったかは記録だけでは証明できない」とも述べている。別の ronthedrummer 氏の環境では trusted_hash の記録は無かった |
| リモート MCP の追加 | mcp.codex.json が https://mcp.postman.com/mcp を指し、認証が必要で起動に失敗したというログが報告されている |
| Copilot CLI への導入 | ck-tecso 氏が ~/.copilot/settings.json に "postman@postman": true を確認したと報告(1人の報告) |
| データの外部送信(流出) | 確認されていない。報告者は「流出を立証するものではない」と明言し、別の報告者も「アップロードされた証拠はない」と述べている |
| Postman 側の反応 | issue 上ではコメント経由の引用のみ(「既存ユーザーへのオプトインを明確にする」という趣旨)。公式な修正版や声明は、11月4日時点で確認できていない |
要するに、確認の度合いが高いのは「同意を求める画面なしに、既存ユーザーの環境へプラグインと CLI が導入され、エージェント側の設定に有効化のエントリが追加された」という点である。一方、「意図的に機密を集めようとしている」「フックで検証を回避している」といった意図に関する主張は、現時点で立証されていない。冷静に設定を確認し、整理するのが適切である。
なぜ問題視されているのか
論点は「データが盗まれたか」ではなく、「同意の境界」である。コーディングエージェントは、ユーザーのリポジトリや認証情報に近い場所で動く。そのエージェントの設定ファイルに、別のアプリが自動でプラグインを足し、さらに起動時の指示(プロンプト)を差し込める状態は、次のようなリスクを持つ。
- 指示の注入面が増える: セッション開始時に毎回、第三者のテキストがエージェントの文脈に入る。内容が穏当でも、後から更新で変わりうる(配布元は git リポジトリで、マーケットプレイスの更新に追従する)
- 外部 MCP サーバーが登録される: 認証すれば、エージェントがツール経由で外部サービスと通信する経路になる。未認証でも、設定として残ること自体が監査対象になる
- 信頼の自動付与: エージェント側にはフックの内容を確認して承認する仕組みがある。報告では、インストーラーがその承認を代行しようとしていたとされる。この点は主張が割れており、確認が必要である
配布経路が悪用された事例は Cursor 版 Claude Code 拡張機能のバックドア で整理している。今回は悪意が確認されていない点で異なるが、本人が把握していない拡張が開発者の端末に入る構図は共通する。
影響を受ける条件
報告から読み取れる範囲で、条件を整理する。確定的な仕様ではない点に注意してほしい。
- Postman のデスクトップアプリを使っている(報告は macOS。Windows・Linux の挙動は今回の資料では確認できていない)
- サインイン済みで、ログに "signedIn":true と "exposed":true が出ている
- 既存インストールが更新された(報告では 12.33.4 の環境と、12.31.3 から 12.35.1 へ更新した環境)。新規インストールで同じ挙動かどうかは、報告者が「クリーンな Mac では再現していない」としており不明
- 同じ端末に Claude Code、Codex、Cursor、Copilot CLI などのエージェントがある。導入先として報告されているのは Claude Code、Codex、Cursor(導入済みと記録)、Copilot CLI(別の報告)
- Postman をブラウザ版のみで使っている場合は、デスクトップアプリの更新処理が走らないため、報告されている現象の対象外と考えられる(推測を含む)
自分の環境の確認方法
以下は macOS/Linux 系のシェルでの確認例である。パスは issue の報告に基づく。読み取りだけで、何も変更しない。
まず、Postman のログに自動導入の記録があるかを確認する(macOS のパス)。
grep -n "auto-existing-upgrade" "$HOME/Library/Application Support/Postman/logs/main.log" | head次に、各エージェントの設定に Postman のエントリがあるかを見る。
grep -n -i postman ~/.claude/settings.json ~/.claude/plugins/installed_plugins.json ~/.codex/config.toml ~/.copilot/settings.json 2>/dev/null
ls -la ~/.local/bin/postman 2>/dev/null
ls -d ~/.claude/plugins/cache/*postman* 2>/dev/nullヒットがなければ、少なくとも報告された場所には痕跡がない。ヒットした場合は、どの設定で有効化されているか(enabled = true、"postman@..." : true など)を確認する。Cursor については、プラグインの管理画面(Settings の Plugins/MCP 周り)に Postman が出ていないかを見る。報告外の場所に入っている可能性もあるため、各ツールのプラグイン一覧も確認するとよい。
削除・無効化の手順
注意: ここで示すのは、各ツールの設定から該当エントリを無効化・削除するという一般的な手順であり、Postman の公式手順ではない。公式の削除手順は 11月4日時点で確認できていない。実行前に設定ファイルのバックアップを取ること。
Postman のメニューに「Help → Postman CLI and Plugins → Uninstall Postman Coding Agent Plugin」という項目があるとの報告がある。ただし ck-tecso 氏は、これを実行しても Copilot 側の設定が残ったと報告している(1人の報告)。メニューを使った場合も、実行後に上の確認コマンドで残りを確認するのが確実である。
Claude Code
Claude Code のプラグイン管理コマンド(/plugin)から Postman のプラグインを無効化・アンインストールできる。画面で操作できない場合は、ユーザー設定ファイル ~/.claude/settings.json の enabledPlugins で該当キーを false にするか、行を削除する。
"enabledPlugins": {
"postman@claude-plugins-official": false
}キャッシュは ~/.claude/plugins/ 以下にある。削除前に他のプラグインと混ざっていないか確認する。公式マーケットプレイスの扱いは claude-plugins-official ディレクトリの解説 も参照。
Codex
~/.codex/config.toml の次の部分を無効化または削除する。マーケットプレイスの定義を残すと、後から再導入されうる。
[marketplaces.postman] # 削除
[plugins."postman@postman"] # enabled = false にするか削除
[hooks.state."postman@postman:..."] # 信頼記録があれば削除Cursor・Copilot CLI など
Cursor は、プラグインと MCP サーバーの一覧から Postman を無効化・削除する。Copilot CLI は ~/.copilot/settings.json の extraKnownMarketplaces と enabledPlugins の Postman 関連を削除または false にする。いずれも、報告に基づく場所であり、バージョンによって異なる可能性がある。
Postman CLI
~/.local/bin/postman と同階層の lib ディレクトリに CLI が置かれたとの報告がある。Postman CLI を使わないなら削除してよいが、自分で入れたものと区別するため、削除前に postman --version や更新日時を確認する。アプリ本体を残す場合に更新で再導入されるかは未確認なので、更新後は確認コマンドを再実行する。
組織としての対策
個人の設定確認だけでは、端末が増えるほど漏れが出る。次のような対応を検討するとよい。
- 端末台帳の棚卸し: Postman デスクトップが入っている開発者・QA 端末を洗い出し、上の確認コマンドを配布して結果を集める
- 設定ファイルの監視: ~/.claude/settings.json、~/.codex/config.toml、~/.copilot/settings.json への変更を、MDM や EDR のファイル監視で検知対象にする。エージェント側の管理ポリシー(組織設定でプラグインの導入元を制限できるか)は、使っているツールの最新ドキュメントで確認する
- 更新の運用: 開発者端末のアプリは更新内容を確認してから展開し、重要な端末では自動更新を止める
- エージェント導入の承認フロー: プラグイン・MCP サーバーの追加を許可制にしている場合、「アプリ側が勝手に追加するケース」も監査対象に含める
- 通信ログ: プロキシ・DNS ログで mcp.postman.com への接続を確認する(あっても流出の証拠ではない)
まず「エージェントの設定に触れうる開発者向けデスクトップアプリ」を一覧にする。全体の備えは ITリスク対策ガイド の考え方に沿って優先度を付けるとよい。
代替ツールの比較
Postman を使い続けるかは、各社のポリシーと用途次第である。移行先を検討する場合に備え、公式サイトで確認できた範囲の特徴を示す。価格や機能は変わるため、導入前に最新の情報を確認してほしい。
| ツール | 公式サイトで確認できた特徴 | 注意点 |
|---|---|---|
| Bruno | 無料・オープンソースと記載。コレクションはファイルシステム上のフォルダとテキストファイルで、Git で管理できる。クラウド同期・アカウント・ログイン不要で、データは手元から出ないと説明している。macOS・Windows・Linux 対応。エンタープライズ向けに SSO/SAML などの機能も案内 | 具体的なライセンス名と価格はトップページに記載がない。公式ドキュメントで確認すること |
| Insomnia | Kong Inc. が提供。オープンソースと無料枠がある。保存先はローカル、Git、クラウドから選べる(クラウドはオプションで E2E 暗号化)。CI 向けの Inso CLI がある | ライセンス名と価格はトップページに記載がなく、GitHub リポジトリや価格ページで確認すること。クラウド保存を選ぶとデータが外部に置かれる |
| Hoppscotch | 「オープンソースの API 開発エコシステム」と記載されている | 今回確認できたのは概要のみ。セルフホストの可否・ライセンス・料金は、公式ドキュメントで確認すること |
Milkman などその他のツールは、今回は公式情報を確認できていないため評価を控える。比較の観点としては、①データの保存場所(ローカル/Git/クラウド)、②アカウントの要否、③更新でエージェント設定に触れないか、④ライセンスと運営母体、を見るとよい。ファイルベースのコレクションを Git で管理しておくと、乗り換えも容易になる。
よくある質問
データは外部に送られたのか
現時点で、データが送られたことを示す証拠は確認されていない。issue の報告者は「流出を立証するものではない」と述べ、別の報告者も「アップロードの証拠はない」としている。「全 API データを共有しようとする」という見出しの言い回しは、確認された事実ではなく解釈である。ただし、MCP サーバーの登録とフックによる指示注入は、条件が揃えば情報の通り道になりうるため、設定は確認しておきたい。
Postman を使っていれば必ず影響を受けるのか
いいえ。報告は、デスクトップアプリの既存インストールがアップグレードされた環境で出ている。ブラウザ版のみの利用や、エージェントを入れていない端末は、報告されている現象の対象外と考えられる。ただし、新規インストールでどうなるかは確認されていないため、確認コマンドで実際の状態を見るのが確実である。
Postman のメニューからアンインストールすれば十分か
メニューに削除項目があるとの報告はあるが、ck-tecso 氏は Copilot 側の設定が残ったと報告している。実行後に、各エージェントの設定ファイルに Postman のエントリが残っていないか確認することを勧める。
Codex のフックが自動承認されていたのか
報告者はソースコード上に承認を行う処理があると説明しているが、信頼記録を誰が作ったかは証明できないとも述べている。別の報告者の環境では信頼記録が無かった。したがって、現時点では未確定であり、断定せずに各自の config.toml を確認するのが適切である。
Postman 側は対応しているのか
issue 上では、コメント経由で「既存ユーザーに対するオプトインを明確にする」という趣旨の Postman の回答が引用されているだけで、出典の確認はできていない。11月4日時点で、公式の修正リリースや公式の削除手順は確認できていない。最新の状況は issue と Postman の公式アナウンスを確認してほしい。
出典
この記事に関連する無料ツール(登録不要・その場で結果)
お気軽にご相談ください
お問い合わせ