Postmanプラグイン：CodexとClaude Codeでの確認・削除
Postmanがコーディングエージェントの設定を変更したか確認し、プロバイダー設定を残して不要なプラグイン、リモートMCP接続、Codexのフック承認記録を削除します。11月5日の変更撤回の発表、Codexの起動時フック削除、標準コマンドとPostmanの削除ツール、残存設定の確認、チーム向けの管理されたフックポリシーを扱います。
目次
CodexやClaude Codeに不要なPostmanプラグインがある場合は、設定のコピーを安全な場所に保存してください。そのうえで、不要なプラグインとCodexに保存されているフックの承認記録を、それぞれ削除します。選んでいないPostmanのMCP接続では認証しないでください。
通常の作業に戻る前に、新しいセッションで結果を確認します。
Postmanのissue #14370では、次のエラーが報告されました。
MCP server startup failed server_name="postman"
... error: Auth required, when send initialize request報告者は、APIの作業中にPostmanのスキルが繰り返し読み込まれる現象も説明しています。これらの症状があれば連携設定を調べる必要があります。ただし、APIのデータがアップロードされた証拠ではありません。
最初の報告後に何が変わったか
2026-11-10時点では、変更撤回の発表とCodexプラグインの修正が行われています。最初の報告で確認されたインストーラーの動作を、現在のすべてのインストール環境でも変わらず起きる動作として扱わないでください。
最初の報告は、macOS上のPostmanデスクトップ12.33.4、Codexプラグイン1.1.0、Claude Codeプラグイン2.0.1に関するものでした。12.35.1についての後続の報告でも、自動インストールが説明されています。ただし、その報告の端末にはCodexフックを信頼するための保存済み記録がありませんでした。Cursorのプラグインも、その起動で追加されたのではなく以前から存在していました。
11月5日、リポジトリのメンバーであるpreethammavinが、Postmanは変更を撤回すると発表しました。これは、GitHub上でメンバーとの関連付けがなかった投稿者による、それ以前のコメントとは区別できます。
同じ11月5日にマージされたプルリクエスト#149では、インストーラー側での承認処理が削除されました。さらにhooks/codex-hooks.jsonが削除され、Codexのマニフェストに"hooks": {}が設定されました。現在のCodexマニフェストも、この空のフック宣言を維持しています。PostmanのスキルとMCPサーバーは引き続き含まれています。
リポジトリにこれらの変更が入ったことと、既存の端末から不要な設定が削除されたことは別です。変更が入ったという事実だけでは、手元の環境の削除結果は確認できません。デスクトップアプリの更新で古い登録や信頼記録も消えたと思い込まず、インストール済みのファイルを確認してください。
削除する前にPostmanが書き込んだ内容を確認する
まずPostmanと、実行中のエージェントのセッションを閉じます。編集前に、影響を受けた設定、インストール記録、関連ログのコピーを非公開の場所に保存してください。
問題が起きたセッションで使われている設定のルートディレクトリを調べます。ターミナルとデスクトップアプリでは、起動時の環境が異なる場合があります。次のBashの確認処理は、CODEX_HOMEと、Claude Codeの文書にあるCLAUDE_CONFIG_DIRによる変更を考慮します。
この確認処理は、対象の文字列を含むファイルの名前だけを表示します。ファイルに保存された設定の内容そのものは出力しません。
codex_root="${CODEX_HOME:-$HOME/.codex}"
claude_root="${CLAUDE_CONFIG_DIR:-$HOME/.claude}"
for file in \
"$codex_root/config.toml" \
"$claude_root/settings.json" \
"$claude_root/plugins/installed_plugins.json"
do
if [ -f "$file" ]; then
grep -ilF -- postman "$file"
fi
done一致したファイルは詳しく調べる対象になりますが、それだけで自動インストールされたとは証明できません。一致がない場合も、分かるのは今回調べたファイル内に該当文字列がないことだけです。
報告されたmacOS環境では、~/Library/Application Support/Postman/logs/main.logを確認します。issueには次のインストール結果が含まれていました。
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}この記録の時刻を、プラグインのインストール記録と照合してください。時系列が一致すれば、設定ファイルで「Postman」という文字列を見つけただけの場合より強い根拠になります。
Codexでは、元の報告にある次の3つの項目を別々に確認します。
| 設定項目 | 確認する内容 |
|---|---|
[marketplaces.postman] | 参照元がhttps://github.com/postmanlabs/postman-plugin.gitかどうか。 |
[plugins."postman@postman"] | プラグインが有効かどうか。 |
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"] | 保存された承認にtrusted_hash、trusted_content_hash、または両方が含まれるかどうか。 |
フックの信頼記録が見つからなくても、プラグイン自体がインストールされていないとは判断できません。後続の報告では、プラグインの存在とフックの承認記録が別であることが示されています。
Claude Codeでは、~/.claude/settings.jsonのenabledPluginsを確認します。報告された識別子はpostman@claude-plugins-officialでした。~/.claude/plugins/installed_plugins.jsonでは、該当するインストールのスコープ、バージョン、installedAt、lastUpdatedを確認してください。
Cursorについては、インストーラーのホスト用アダプターに次の2つの場所が記載されています。
~/.cursor/plugins/local/postman
~/.cursor/plugins/cache/cursor-public/postmanこの2つの場所を、Postmanがインストールされているか調べる手がかりにしてください。ディレクトリがあるだけでは、そのプラグインが現在有効かどうかは分かりません。有効状態はCursorのプラグイン設定で確かめます。
設定やログの全体は公開しないでください。認証情報、内部のパス、アカウント情報が含まれる場合があります。共有するのは関連部分だけにし、機密情報を伏せてください。
プラグインと保存された信頼記録を別々に削除する
各ツールの標準コマンドか、Postmanの削除ツールのどちらかを選びます。すべての方法を無条件に順番に実行しないでください。
各ツールの標準コマンドで対象を指定して削除する
報告されたCodexプラグインの識別子に対しては、Bashで次を実行します。
codex plugin remove postman@postman次に、そのマーケットプレイスの参照元を確認します。必要な別のプラグインが使っていないことを確認してから、マーケットプレイスを削除してください。
codex plugin marketplace remove postmanこれらは、現在のPostmanのCodex用アダプターが行う操作と一致します。古いインストールが別の識別子で登録されている場合は、例の名前をそのまま使わないでください。端末上で確認した登録に対応する、実際の識別子を使います。
報告にあるユーザースコープのClaude Codeプラグインには、次を使います。
claude plugin uninstall postman@claude-plugins-official --scope userClaude Codeのプラグインコマンドのリファレンスは、user、project、localのスコープを区別しています。プロジェクトまたはローカルのインストールと確認できた場合は、そのプロジェクト内で該当スコープを指定してください。プロジェクトの共有設定を削除するときは、チームと調整します。
1つのプラグインを削除するために、claude-plugins-officialマーケットプレイス全体を削除しないでください。installed_plugins.jsonを空にしたり、設定ファイル全体を置き換えたりしないでください。
インストール済みのCLIがコマンドを受け付けない場合は、先にそのCLIのplugin --helpを確認します。未対応のアンインストールコマンドの代わりに、ディレクトリを広範囲に削除しないでください。
別の方法：Postmanの文書にある削除ツールを使う
Postmanの現在のリポジトリの手順には、次の削除コマンドがあります。
npx @postman/postman-plugin@latest removeこの方法は、パッケージのコードを確認して実行を認め、影響を受けるエージェントを調べてから使ってください。現在のインストーラーのソースでは、Node.js 22以降が必要です。**remove**サブコマンドを省かないでください。これを付けずにインストーラーを実行しても、削除操作にはなりません。
文書によると、この削除ツールはプロジェクトスコープのインストールを残します。現在のCodex向け実装は、古い起動時フックの承認を取り消す処理も試みます。
この最後の処理は別途確認が必要です。承認取り消しの実装は、削除全体を失敗扱いにせず、残存設定の削除で問題が起きたと報告する場合があります。警告を読み、実行後にファイルを確認してください。
残っているCodexの承認を削除する
対象のCodexユーザー設定に次のサブセクションが残っている場合は、全体を削除します。
[hooks.state."postman@postman:hooks/codex-hooks.json:session_start:0:0"]このブロックは、削除対象のセクションを示しています。設定に追加するものではありません。
削除するのは、このPostman用サブセクションの見出しと、そこに属するtrusted_hashおよびtrusted_content_hashです。両方のフィールドがある場合は、片方だけを残さずまとめて削除してください。次のTOMLテーブルの見出しに達したら、それ以降は削除しません。hooks.state内のほかの項目は残します。
手動編集では、Postmanの項目と確認できたものだけを削除します。model_provider、model_providers、base_url、認証設定、無関係なフックは保持してください。Claude Codeでは、無関係なenvや権限設定も残します。
標準コマンドで削除した後は、該当プラグインとマーケットプレイスの登録がなくなったことを確認します。どちらの方法でも、Postmanの承認記録が削除されたか確認してください。アンインストールの完了メッセージだけでは、この3つの条件を満たしたとは判断できません。
Cursor、個別のMCP設定、CLIを確認する
Cursorのマーケットプレイス経由のインストールには、追加の操作が必要です。Cursor Settings > PluginsでPostmanをアンインストールし、Cursorを再起動してください。どちらの削除方法でも、Cursorのプラグイン一覧にPostmanが残っていないか確認します。
MCPの警告が残る場合は、警告を消すためにサインインせず、サーバー設定を調べてください。Bashで、影響を受けた各ツールに対応するコマンドを使います。
codex mcp list
claude mcp list個別に設定されたサーバーは、別途削除する必要があります。不要な独立した項目の名前がpostmanであることを確認してください。そのうえで、codex mcp remove postmanまたはclaude mcp remove postmanを使います。削除前に、その設定のスコープも確認してください。Codex CLIのリファレンスとClaude CodeのMCPドキュメントに、これらのコマンドが記載されています。
独立したサーバー設定と、有効なプラグインが提供する接続を混同しないでください。プラグイン由来の接続は、そのプラグインを削除します。
Postman CLIも別途確認します。Bashのtype -a postmanは、検索パスで見つかった該当コマンドを表示します。元の事例では実行ファイルが~/.local/binにありましたが、すべての環境で同じ場所とは限りません。
Postmanのインストール方法別のCLI削除手順に従ってください。npm以外でインストールした場合は、文書では実行ファイルを削除する方法が示されています。付随するファイルは内容を確認してから削除します。報告に登場したという理由だけで、共有のlibディレクトリを削除しないでください。
新しいセッションで削除結果を確認する
警告が消えたかだけではなく、設定と読み込まれる構成要素を確認してください。
まず、対象ツールのプラグイン一覧を確認します。
codex plugin list --json
claude plugin list --jsonマーケットプレイスの接尾辞やスコープが異なるものも含め、Postmanの登録をすべて調べます。実際に使われているCodex設定から、上記のPostmanフック承認サブセクションがなくなったことを確認してください。
検証用の使い捨ての作業コピーで、エージェントの新しいセッションを開始します。不要なPostmanプラグインやMCP接続が読み込まれないか確認してください。削除した連携が原因のPostman認証警告は、新たに出ないことが期待されます。
古い会話にPostmanへの言及が残っていることだけを、判定材料にしないでください。会話の履歴とインストール済みの設定は別のものです。そのため、Claude Codeで新しいセッションを始めることと、既存セッションを圧縮することの違いが重要です。
Postmanがまだ現れる場合は、設定のルート、インストールスコープ、残っているプラグイン登録、個別のMCP設定を確認します。有効な設定元を特定せず、同じ既定のファイルを繰り返し削除しないでください。
Postmanデスクトップを使い続ける場合は、次の管理された起動や更新の後にも設定を比較します。項目が復活したら、ログの新しい時刻と設定の差分を保存してください。どのプロセスが再作成したか調べる間は、そのデスクトップアプリの展開を一時停止します。
なぜインストーラーがCodexのフック承認を書き込めたのか
以前のインストーラーは、Codexの設定インターフェイスを使って承認を保存していました。プラグインを登録した後、信頼するかどうかを対話的なレビューに任せるだけではありませんでした。
コミット6c8e452e0f4237f4bcc0901cb1ac442dec707e49では、フックの登録にSessionStartと、startup|clear|compactというmatcherが使われていました。指示文は、単純なものを除くAPIエンジニアリング作業でpostman:api-engineerを使うよう求めていました。
この指示は、Postmanの利用を明示的に依頼された場合に限りません。質問への回答だけの場合やごく簡単な編集は除外され、ユーザーの指示が優先されるとも書かれていました。
以前のapprovePostmanHookの実装は、codex app-serverを起動します。hooks/listでフックの現在のハッシュを取得して確認し、config/batchWriteを呼び出していました。その書き込みで、hooks.stateにtrusted_hashが追加されます。
ここから確認できるのは、承認を試みる処理があったことです。すべてのCodexバージョンで成功したとは限りません。また、特定の端末にある既存の記録を誰が作ったかも特定できません。
Codexの文書化された信頼の仕組みは、フックと保存済みのハッシュを比較します。新規または変更されたフックは、レビューと承認が済むまで実行されません。したがって、重要な境界は承認状態にアクセスできるかどうかです。ハッシュの一致だけでは、人がフックを承認した証拠にはなりません。
実務上の問題はローカルのアクセス権にあります。エージェント設定に十分なアクセス権を持つソフトウェアは、安全性に関わる状態を変更できます。プラグインの有効化、フックへの信頼、リモートMCPの認証は別々の制御です。1つだけを削除しても、ほかが設定されたまま残る場合があります。
チームの端末で再び設定を書き換えられないようにする
機密情報を除いた承認済みの設定を基準として保存し、ツールのインストールや更新後に比較してください。バージョン管理にはテンプレートとレビュー済みの変更を保存します。有効な認証情報や個人用設定ディレクトリ全体は保存しないでください。
差分は変更を検出しますが、同じアカウントのプロセスによるファイル書き込みは防ぎません。制限を強制するには、通常のデスクトップアプリが書き換えられない、管理者の管理下にあるポリシーを展開してください。
macOSまたはLinuxのCodexでは、システム要件ファイルは/etc/codex/requirements.tomlです。既存ファイルの最上位に、次の設定を追加します。
allow_managed_hooks_only = true管理された設定のドキュメントに、展開先の場所が説明されています。設定リファレンスによると、この設定はユーザー、プロジェクト、セッション、プラグインのフックを実行対象から外します。管理されたフックは引き続き許可されます。
macOSのClaude Codeでは、既存の/Library/Application Support/ClaudeCode/managed-settings.jsonに次を組み込みます。
{
"allowManagedHooksOnly": true
}これは管理ポリシーの設定であり、ユーザー設定の編集を代替するものではありません。Claude Codeのフック制御は、ユーザー、プロジェクト、その他のプラグインのフックをブロックします。設定リファレンスには重要な例外があります。管理されたフック、SDKフック、管理設定のenabledPluginsで強制的に有効化されたプラグインのフックは許可されます。
広く展開する前に、チームが実際に使うクライアントのバージョンでポリシーを検証してください。フックの制限自体は、プラグインのアンインストールやMCP接続の削除を行いません。それらは別に管理します。
ダウンロードした指示ファイルやプロバイダー設定にも、同じ確認を広げてください。CodexとClaude Codeの設定監査ガイドでは、動作中のモデル設定を失わずに変更を見つけるための、より広い確認項目を紹介しています。
