Codex n8n MCP接続の設定と使い方｜CLI連携の実用手順

Codex n8n MCPとは何か — 役割を分けると理解しやすい

MCPは、AIアプリケーションが外部のサービスや道具へ接続するための共通ルールです。Codex CLIがMCPクライアントとして動く場合、Codexは接続先が提供する道具の名前、入力項目、返ってくる結果を読み取り、必要な場面で呼び出します。n8nはMCPサーバーとして、あらかじめ外部から利用できるようにした処理やデータ操作の入口を提供します。両者の間に独自の変換コードを毎回用意するのではなく、接続先の説明を読みながら会話の中で利用できる点がMCPの利点です。

この関係は、Codexがn8nを「操作するアプリ」になるという意味ではありません。Codexはコードベースの調査、修正、テストを担当し、n8nは登録されたサービスへの接続や定型処理を担当します。たとえば、Codexにリポジトリの変更内容を整理させ、その結果をn8n側の通知処理へ渡すことはできますが、接続しただけで何でも実行されるわけではありません。n8n側で公開されている範囲と、現在の利用者に認められた操作が前提になります。

OpenAIのCodexリポジトリでも、Codex CLIがMCPサーバーへ接続するクライアントとして動くこと、codex mcp で登録済みの接続先を管理できることが説明されています。仕様は版によって変わり得るため、手元のコマンドの結果を基準にしつつ、Codex CLIのMCPインターフェースと公式リポジトリのREADMEを合わせて確認してください。

MCPクライアントとMCPサーバーを分ける

同じn8nとMCPという言葉が出てきても、n8nをクライアントにする構成と、n8nをサーバーにする構成があります。n8nのMCP Client Toolは、n8n内の処理から別のMCPサーバーを呼び出すためのものです。今回のテーマは反対方向で、Codex CLIからn8nのMCPサーバーへ接続します。どちらを設定するかで、URLを入力する画面、必要な権限、最初に確認するログが変わります。

Codex側で登録するのは、n8nが公開するMCPサーバーのURLです。n8n側のMCP Client Toolを追加しても、Codex CLIの接続先は増えません。まず「どちらがクライアントで、どちらがサーバーか」を紙に書くように整理すると、設定項目の取り違えを減らせます。n8n公式のBuild with MCPの説明でも、AIツールをMCPクライアント、n8nをMCPサーバーとして接続する考え方が案内されています。

n8nの二つの公開方法を混同しない

n8nには、インスタンス全体で提供するMCPサーバーと、特定の一つの処理だけをMCPサーバーとして公開するMCP Server Triggerがあります。前者は、n8n内で利用を許可された複数の処理を検索・確認・呼び出しする構成です。後者は、公開したい道具を自分で組み立て、その入口だけを外部のAIアプリへ見せる構成です。

初めて試すときは、広い権限を持つインスタンス全体の接続をいきなり使わず、対象を絞ったMCP Server Triggerから始める方法もあります。逆に、n8n内の既存処理を横断して調べたいなら、インスタンス単位のMCPが向いています。選択を曖昧にしたまま接続すると、Codexから見える道具が多すぎたり、期待した処理が表示されなかったりするため、導入前に目的を決めておきましょう。

2026年8月に確認した更新 — CLI版とn8n版は別々に見る

今回の接続を今確認する理由の一つは、Codex CLIの版が短い間隔で更新されていることです。OpenAI公式リリースページでは、2026年7月31日にCodex CLI 0.147.0-alpha.4がプレリリースとして公開されています。これは安定版の番号と同じ意味ではなく、先行検証用の版が公開されたという情報です。導入時には「最新の数字」だけで判断せず、安定版かプレリリースか、使っている導入経路は何かを分けて記録します。

このリリースページにn8n固有の接続変更が書かれている、という意味ではありません。大切なのは、MCP接続を組んだ後にCLIを更新すると、接続の表示や設定項目をもう一度確認する価値があるということです。Codexの版番号はクライアントの更新履歴、n8nの版番号はサーバー側の機能や表示の更新履歴であり、片方が変わったからもう片方も同じ版になるわけではありません。

また、n8nの公式ブログは、内蔵MCPサーバーで処理の作成・更新・検証を行う機能について、n8n 2.18.4以上を推奨しています。環境によって利用可能な機能や画面は異なるため、導入前に公式のMCPサーバー案内と自分のn8nの版番号を照合してください。Codex CLIの更新とn8nの更新を一つの変更として扱わないことが、原因の切り分けを簡単にします。

版番号と機能追加を同一視しない

たとえば、Codex CLIが0.147.0-alpha.4になったからといって、n8nのMCPサーバーが新しい道具を持つとは限りません。反対に、n8n側が更新されても、Codex CLIが古い版のままだと、URLの扱いや表示が現在の説明と一致しない場合があります。検証時は、Codex CLIの版、n8nの版、接続URL、表示された道具の数を別々にメモします。

リリースの内容が詳しく書かれていないプレリリースを日常の中心に置く必要もありません。新しい接続を試すために先行版を使う場合は、読み取り中心の検証用環境に限定し、安定版へ戻せる導入方法を残しておくと安心です。版番号を新しさの順位ではなく、検証条件の一つとして扱うのが現実的です。

n8nの対応条件を先に確認する

n8nのMCPサーバーは、接続先のURLを知っているだけで利用できる機能ではありません。管理画面でMCPサーバーを有効にし、利用者へ接続を認め、外部から見せる処理を選ぶ必要があります。n8n公式案内は、接続情報の発行とクライアントごとの設定を分けて説明しているので、画面を見ずにURLを推測しないでください。

特に、n8n Cloudと自己管理型のn8nでは、ホスト名や管理画面の位置が異なります。記事中のhttps://YOUR_N8N_HOST/mcp-server/httpは形を示す例であり、そのまま入力する値ではありません。実際に表示された接続先を使い、末尾のパスを独自に変えないことが最初の確認になります。

接続前に決めること — URL・公開範囲・認証情報

Codex n8n MCPの設定で迷いやすいのは、コマンドそのものよりも「何を公開し、どこまで呼び出せる状態にするか」です。URLを登録すればCodexがn8n内の全データを読めるわけではなく、n8n側の利用者権限、処理の公開設定、MCPサーバーの認証が順番に適用されます。反対に、広すぎる範囲を公開すると、Codexが選択できる道具が増え、依頼の意図と異なる処理を候補にする可能性があります。

おすすめは、最初に「読むだけの処理」と「変更する処理」を分けることです。読み取り用の処理は、一覧、詳細、状態確認のように結果が外部へ影響しないものを選びます。変更用の処理は、作成、更新、送信、削除などを含むため、名前と入力項目を把握してから別に公開します。この線引きをn8n側で先に行えば、Codexへの依頼文が短くても安全な候補を選びやすくなります。

接続方式は、現在のCodex CLIで利用できるStreamable HTTPを基本にします。OpenAIの設定スキーマには、URL、アクセストークンを読む環境変数名、HTTPヘッダーなどの項目が定義されています。細かな設定項目は版で増減するため、手作業で全項目を記述するより、まず公式コマンドで登録してからcodex mcp get n8n --jsonで結果を見る方が確実です。仕様の根拠はCodexの設定スキーマで確認できます。

n8n側は「見せる処理」を先に絞る

n8n側でMCPを有効にしたら、Codexから見せる対象を一覧にします。名称だけで判断せず、入力値、読み取りか変更か、外部サービスへ送信するか、失敗時に再実行しても問題ないかを確認してください。処理の説明が曖昧なら、Codexの性能で補うのではなく、n8n側の説明を先に書き直す方が効果的です。

公開範囲を少しずつ広げる運用にすると、接続後に表示される道具の変化を追跡できます。最初は一つか二つの読み取り処理だけにし、Codexの一覧で名前と説明が期待どおりに出ることを確認します。その後に変更処理を一つずつ追加し、追加前後で入力項目と実行結果を比べます。

Codex側はHTTP接続を優先する

以前のMCPサーバーには、ローカルのプログラムを起動して標準入出力で通信するものもありました。n8nのインスタンス単位MCPはHTTPエンドポイントを使うため、現行のCodex CLIではURLを直接登録する方法が分かりやすいです。URLを別の中継プログラムへ渡す構成を増やすと、ポート、プロセス、ログの確認箇所が増え、問題が起きたときにn8nとCodexのどちらが原因か追いにくくなります。

ただし、ネットワークの制約で外部URLへ接続できない環境では、自己管理型の中継やローカル接続が必要になることがあります。その場合も、まず直接URLで接続できるかを確認し、後から中継を加えます。構成を一度に複雑にしないことが、MCPの切り分けでは重要です。

アクセストークンは設定値と分離する

接続に使うアクセストークンを、記事、リポジトリ、共有画面、config.tomlのURL欄へ直接書かないでください。Codex CLIには、トークンそのものではなく、トークンを読み取る環境変数の名前だけを登録する方法があります。n8n側でトークンを再発行した場合も、Codexの接続定義を作り直さずに値だけを差し替えられます。

Windowsでは、PowerShellの現在のプロセスにだけ環境変数を設定して試せます。確認が終わった後に同じターミナルを閉じれば値は引き継がれません。長期利用では、OSの管理機能や会社の規定に沿って保管し、端末の履歴や画面共有に残さないようにしてください。

Codex CLIからn8nを追加する手順

ここでは、n8nがインスタンス単位のMCPを有効にし、Streamable HTTPの接続先とアクセストークンを用意できている前提で進めます。n8nの管理画面の名称は版によって変わる可能性があるため、実際の画面に表示された値を使ってください。コマンドはWindows PowerShellを想定していますが、macOSやLinuxでも環境変数の指定方法を置き換えれば同じ考え方で進められます。

登録作業は、n8nで見た値とCodexの設定を一つずつ照合しながら進めます。

Step 1: n8nで接続先と公開範囲を確定する

n8nのMCP設定を開き、サーバーが有効になっていること、対象の利用者が接続できること、公開対象の処理が選ばれていることを確認します。接続先の例は次の形です。

https://YOUR_N8N_HOST/mcp-server/http

YOUR_N8N_HOSTは、自分のn8nのホスト名へ置き換えます。/mcp-server/httpを/mcpや/apiへ変えると別の入口になるため、公式画面に表示されたパスをそのまま使います。n8nの公式ドキュメントでも、MCPサーバーへの接続、認証、公開対象の設定は個別の手順として案内されています（出典: n8n MCPサーバー接続ガイド）。

Step 2: PowerShellでアクセストークンを渡す

n8nで発行したアクセストークンを、接続定義で参照する名前に設定します。値は例なので、実際のトークンを記事や共有メモへ貼り付けないでください。

$env:N8N_MCP_TOKEN = "<n8nで発行したアクセストークン>"

この指定は、現在開いているPowerShellから起動するCodex CLIに適用されます。別のターミナルを開いた場合は、そのプロセスに値がありません。$env:N8N_MCP_TOKENを画面に表示して確認する方法は、値が履歴やログへ残るおそれがあるため避けます。接続後に不要になったら、PowerShellを閉じるか、現在のプロセスから値を削除します。

Remove-Item Env:N8N_MCP_TOKEN -ErrorAction SilentlyContinue

Step 3: Codex CLIへURLを登録する

Codex CLIの公式コマンドで、接続名、URL、トークンを読む環境変数名を登録します。

codex mcp add n8n --url https://YOUR_N8N_HOST/mcp-server/http --bearer-token-env-var N8N_MCP_TOKEN

このコマンドは、Codexの設定にn8nという名前のStreamable HTTP接続を追加します。URLの値にトークンをクエリ文字列として足す方法は、履歴やログへ残るため使わないでください。--bearer-token-env-varは、実際の値ではなく環境変数の名前を渡すオプションです。オプションの形式は、OpenAI公式ソースのcodex mcp add定義でも確認できます。

もしコマンドが認識されない場合は、Codex CLIが古い版である可能性があります。まずcodex --versionを確認し、導入経路に合った更新方法を公式リリースページで確認してください。先行版へ急いで切り替えるのではなく、現在の版で利用できるcodex mcp --helpの表示を基準にするのが安全です。

Step 4: 登録内容を表示する

登録直後は、値を再表示するのではなく、接続名とURLが正しいかを確認します。

codex mcp list
codex mcp get n8n --json

表示にn8nがあり、URLが期待したホストと/mcp-server/httpで終わっていることを確かめます。アクセストークンの実値が画面へ表示されないことも確認します。名前を間違えた場合は、既存の定義を削除してから正しい名前で登録し直します。

codex mcp remove n8n

ただし、削除は設定を消す操作なので、実行前にcodex mcp get n8n --jsonの結果を必要に応じて保存してください。登録と削除を繰り返すより、最初に接続先の文字列をn8nの画面と照合する方が効率的です。

Step 5: Codexの新しいセッションで確認する

MCPサーバーの道具一覧は、Codexの起動時やセッション開始時に読み込まれる場合があります。登録後に既存の会話だけを見て判断せず、Codex CLIを再起動してから確認します。最初の依頼は「n8nから利用できる処理の名前と説明を読み取り専用で一覧し、変更は行わない」といった範囲にします。

期待した名前が表示され、入力項目と読み取り・変更の違いが説明できれば、接続の第一段階は完了です。表示されない場合は、すぐに処理を追加したり権限を広げたりせず、後述のトラブルシューティングへ進みます。

config.tomlで確認する内容 — CLI登録後に読む

Codex CLIのcodex mcp addを使うと、通常はCodexの設定ファイルへ接続定義が書き込まれます。自分で編集する場合の形は次のようになります。

[mcp_servers.n8n]
url = "https://YOUR_N8N_HOST/mcp-server/http"
bearer_token_env_var = "N8N_MCP_TOKEN"

この例では、URLと環境変数名だけを設定しています。トークンの実値は書きません。古い記事にはmcpServersというJSON風の名前や、標準入出力向けのcommandとargsだけが載っていることがありますが、Streamable HTTPの接続では意味が異なります。現在の設定項目は、OpenAI Codexの設定スキーマと、手元のcodex mcp --helpを合わせて確認してください。

同じ名前の設定ブロックを二つ置くと、TOMLの読み込みでエラーになったり、どちらを使うか分からなくなったりします。既存の[mcp_servers.n8n]がある場合は、追加で同名ブロックを作らず、一つに統合します。設定を編集した後は、codex mcp get n8n --jsonでURLと参照する環境変数名を確認し、Codexを再起動します。

全体設定とプロジェクト設定を使い分ける

複数のリポジトリで同じn8nへ接続するなら、ユーザーのCodex設定へ登録する方法が扱いやすいです。一方、特定のプロジェクトだけで使う場合は、プロジェクト側の設定機能が現在のCLI版でサポートされているかを確認し、対象範囲を限定します。プロジェクトに設定を置く場合も、トークンの実値を保存しないことが最優先です。

共有リポジトリへ設定を置くと、他の利用者の環境でも接続定義が読み込まれる可能性があります。接続先の名前とURLだけを共有し、利用者ごとの環境変数やn8n側の権限は分ける設計にすると、誰がどの処理を呼び出せるかを管理しやすくなります。設定ファイルをコミットする前に、値が残っていないか目視で確認してください。

接続定義の調整は一つずつ行う

接続が不安定なときに、URL、トークン名、タイムアウト、公開範囲を同時に変更すると、何が効いたのか分からなくなります。まずURLだけをn8nの画面と一致させ、次にトークンの参照名、最後に公開対象を一つずつ確認します。codex mcp listの表示、n8n側のアクセス記録、Codexの道具一覧を同じ時刻でメモすると、変更の前後を比べやすくなります。

最初の検証 — 読み取りから小さく始める

接続できた後に重要なのは、Codexがn8nの道具を呼べるかだけでなく、どの道具をどの条件で呼ぼうとしているかを人が読める状態にすることです。n8n公式のMCPサーバー道具リファレンスには、一覧取得、詳細確認、処理の開始、結果の確認など、用意された操作の説明があります。実際に使える範囲はn8nの版と権限で変わるため、記事の説明をそのまま自分の環境の許可とみなしてはいけません。

最初の依頼は、書き込みを伴わない調査にします。たとえば「利用可能な処理を名前、説明、読み取りか変更かの分類で整理し、何も変更しない」と伝えます。次に一つの対象の詳細だけを取得し、入力項目の意味と戻り値を確認します。この二段階を終えてから、テスト用データを使った呼び出しを検討すると、想定外の対象を選ぶ確率を下げられます。

Codexが「この処理を実行します」と表示したときは、処理名、対象、入力値、実行モード、結果の保存先を読みます。依頼文に「確認して」と書いたのに変更用の処理が候補になった場合は、実行せずにn8n側の説明や公開範囲を直してください。曖昧な依頼をモデルの判断だけで埋めるのではなく、入力を具体化することが品質につながります。

読み取り専用の確認を行う

まず、n8nに接続できたことと、処理を呼び出せることを別々に確認します。接続確認だけなら、道具の名前と説明を取得する依頼で足ります。次に、対象を一つに限定して詳細を読みます。戻り値に個人情報や業務上の機密が含まれる可能性がある場合は、テスト用の対象に置き換え、画面共有やログ保存の範囲も確認してください。

変更前に入力値を固定する

作成や更新を伴う処理を試すときは、対象ID、送信先、本文、実行モードを一つの依頼で明示します。「適切に更新して」のような表現は避け、変更対象と変更しない対象を分けて書きます。Codexが入力値を補完しようとしたら、補完を認める前に一覧を表示させます。外部サービスへ送信する処理は、テスト用の送信先を使い、結果を確認してから本番の対象へ移します。

実行結果をn8n側でも確認する

Codexの返答だけを成功の証拠にしないでください。n8nの実行履歴、対象データ、外部サービスの受信結果を確認し、返答と実際の状態が一致しているかを見ます。接続先の処理が非同期で結果を返す場合は、開始と完了を分けて扱います。失敗した場合も、同じ入力で何度も繰り返す前に、エラーの位置と再試行してよい条件を確認します。

接続トラブルの切り分け — エラーを層に分ける

MCP接続の失敗は、URL、ネットワーク、認証、公開範囲、Codex側の読み込みのどこでも起こります。一つのエラーメッセージだけで原因を決めず、外側から順に確認します。最初にn8nの管理画面でMCPが有効かを見て、次にブラウザやネットワークからホストへ到達できるかを確認し、その後にアクセストークン、最後に道具の公開範囲を調べます。

問題を一度に直そうとせず、通信、認証、公開範囲、読み込みの順で切り分けると、再現条件を保ったまま原因を追えます。

401や403が出るとき — 認証情報と権限を見る

HTTPの401や403は、まず環境変数がCodexを起動した同じPowerShellプロセスに存在するか、参照名の綴りが一致しているかを確認します。N8N_MCP_TOKENという名前を登録したのに、実際の環境変数がN8N_TOKENなら、Codexは値を読めません。次に、n8n側でトークンが期限切れになっていないか、利用者にMCP接続の権限があるかを確認します。

URLへトークンを足して試す方法は、履歴やアクセス記録に値が残るため避けます。トークンを再発行した後も接続できない場合は、古い値が別のターミナルやサービスに残っていないかを確認し、必要なら現在のプロセスを閉じてから新しい値で試します。

道具が表示されないとき — n8n側の公開範囲を見る

接続名は表示されるのに道具が一つも見えない場合、URLや認証だけでなく、n8n側でMCPに公開する対象が選ばれているかを確認します。インスタンス単位のMCPとMCP Server Triggerを取り違えていると、別の入口へ接続している可能性があります。また、権限のないプロジェクトにある処理は一覧へ出ないことがあります。

公開対象を追加した後は、既存のCodexセッションをそのまま使わず、新しいセッションで一覧を取り直します。n8nの版が公式推奨条件より古い場合は、まずn8nの更新可否と互換性を確認します。表示されないからといって、同じ処理を何度も公開し直すのは避けてください。

接続が途中で切れるとき — HTTP経路を確認する

接続開始後に切れる場合は、プロキシ、TLS証明書、ファイアウォール、接続保持時間を確認します。/mcp-server/httpを別のパスへ転送しているなら、リクエストのパスとレスポンスの種類が変わっていないかを見ます。自己管理型n8nを外部から利用する場合は、ホスト名を直接開けるか、同じネットワークからCodexを起動した場合だけ成功するかを比べると、ネットワーク層の問題を切り分けられます。

短い処理は通るのに長い処理だけ切れる場合、n8nの処理時間とCodex側のツール待ち時間を別々に確認します。タイムアウトを大きくする前に、対象を小さくして同じ接続が維持されるかを試します。リトライは外部サービスへ二重送信する可能性があるため、変更を伴う処理では特に慎重に扱います。

Windowsで再起動後に動かないとき — プロセスを確認する

PowerShellで設定した環境変数は、そのPowerShellから起動した子プロセスへ渡されます。新しいターミナル、IDE内蔵ターミナル、タスクバーから起動したCodexは、別の環境を持つことがあります。まず同じターミナルでcodex mcp get n8n --jsonを実行し、次に同じターミナルからCodexを起動します。

IDEから起動する場合は、IDEを開き直した後に環境変数が引き継がれているかを、値そのものを表示せずに存在確認します。会社の端末管理ルールがある場合は、それに従ってユーザー環境変数や資格情報の保管場所を決めます。接続設定を複数の場所へコピーして帳尻を合わせると、後でどの値を更新すべきか分からなくなるため避けましょう。

実用例 — コード作業とn8nの処理を分けて使う

Codex n8n MCPは、コード編集をn8nへ丸投げするための機能ではありません。Codexがコードベースを調べて判断し、n8nが外部サービスとの接続を担当するように分けると、責任範囲が分かりやすくなります。Codexの依頼文には、どの段階でn8nを使ってよいか、読み取りだけか、変更まで許可するかを書いておきます。

たとえば、次のような三段階に分けると初回でも確認しやすくなります。

1. Codexにリポジトリの変更点とテスト結果を整理させ、n8nから利用できる処理の一覧と説明を読み取る。
2. 対象を一つに限定し、入力値を明示したうえで、テスト用のn8n処理を呼び出して結果を確認する。
3. 人が結果と対象を承認してから、必要な変更処理や外部サービスへの送信を一回だけ行う。

この順序なら、接続確認、入力の確認、外部への影響が分かれます。最初から「リポジトリを調べて、n8nで適切な処理を選び、結果を送って」と一文で頼むと、Codexが対象や送信先を補う余地が大きくなります。作業が長いほど、調査、判断、変更、結果確認を別の依頼に分ける方が、差し戻しもしやすくなります。

リリース確認に使う場合

Codexがリリース候補の変更点を調べ、n8nが登録済みの通知先や記録先へ結果を渡す構成では、両者の得意分野を分けられます。Codex側では対象の版、変更ファイル、テスト結果を整理し、n8n側では受け取る項目を固定します。実行前に通知先をテスト用へ切り替え、内容と宛先を人が確認します。

ここで重要なのは、Codexの説明が正しいことと、n8nが実際に送信したことを別々に確認することです。Codexの返答に成功とあっても、n8n側で失敗している可能性があります。送信結果の記録とCodexの返答を突き合わせ、再送する場合の条件を決めておきます。

データ確認に使う場合

n8nに保存された表や処理結果をCodexに読み取らせ、コードの変更方針やテスト項目を考える使い方もできます。読み取り対象をプロジェクト単位、日付単位、件数単位で絞り、不要なデータをCodexの文脈へ渡さないことが大切です。個人情報や業務上の機密が含まれる場合は、匿名化した検証データで接続を確かめます。

データを読めることは、データを変更できることと同じではありません。読み取り用と更新用の処理をn8n側で分け、最初のCodex接続には読み取り用だけを見せます。更新が必要になったときは、対象ID、変更項目、実行後の確認方法を明示し、一回の小さな変更で結果を確かめます。

更新時の確認方法 — Codexとn8nを別々に記録する

Codex CLIやn8nを更新したときは、接続が動いたかどうかだけでなく、何が変わったかを記録します。最低限、Codex CLIの版、n8nの版、接続URL、公開対象、トークンを参照する環境変数名、読み取れた道具の一覧を残します。トークンの実値を記録する必要はありません。

更新直後の確認は、次の順序で行うと短時間で終わります。

1. Codex CLIでcodex --versionを実行し、安定版かプレリリースかを記録する。
2. n8nの管理画面で版番号、MCPの有効状態、公開対象を確認する。
3. codex mcp listとcodex mcp get n8n --jsonで接続定義を確認する。
4. 新しいCodexセッションから、読み取り専用の一覧と詳細確認を行う。
5. 変更を伴う処理は、必要性と入力値を人が確認してから一件だけ試す。

この確認で問題が出た場合、まず更新前の版へ戻せるかを確認し、次にURLや権限を変えずに同じ条件で再現します。複数の要素を同時に変えると原因が分からなくなるため、CLIだけ、n8nだけ、公開範囲だけという単位で比較します。OpenAIのリリース一覧とn8nの公式接続案内を、更新日ごとの一次情報として参照してください。

まとめ — Codex n8n MCPは接続後の境界設計が要点

Codex n8n MCPの設定は、URLを一行登録して終わる作業ではありません。Codex CLIをMCPクライアント、n8nをMCPサーバーとして分け、n8n側で公開対象と権限を絞り、Codex側ではStreamable HTTPの接続とアクセストークンの参照名を設定します。現在のCodex CLIでは、codex mcp add、codex mcp list、codex mcp getを使って、登録内容を確認できます。

導入時は、n8nの接続先を画面から取得し、PowerShellの環境変数へ値を渡し、読み取り中心の処理だけを新しいCodexセッションで確認します。道具が見えないときは公開範囲、401や403なら認証情報と権限、途中で切れるときはHTTP経路と処理時間を順番に調べます。Codex CLI 0.147.0-alpha.4のようなプレリリースを確認するときも、CLIの版番号とn8nの版番号を別々に扱ってください。

最後に、接続できたことと、外部処理を実行してよいことは同じではありません。調査、入力確認、テスト、変更の順に小さく進め、n8n側の実行履歴とCodexの返答を突き合わせます。公式情報は更新されるため、設定の根拠にはOpenAI Codex公式リポジトリ、Codex CLIのリリース一覧、n8n MCP公式ドキュメントを使い、導入した版と同じ条件で確認するのが安全です。