Codex CLIのMCP連携ガイド｜サーバー追加とconfig.toml設定

Codex CLIでMCP（Model Context Protocol）サーバーを使うと、外部ドキュメントやブラウザ操作ツールなどをCodexから直接呼び出せるようになる。公式ドキュメントは「Model Context Protocol（MCP）はモデルをツールやコンテキストに接続する仕組みであり、ChatGPTやCodexにサードパーティのドキュメントへのアクセスや、ブラウザやFigmaのような開発者向けツールとの連携を与えるために使う」と説明している（OpenAI公式 Model Context Protocol、2026年9月24日取得）。結論として、Codex CLIでMCPサーバーを使い始める最短ルートは、コマンド1行のcodex mcp addで追加するか、~/.codex/config.tomlに[mcp_servers.<server-name>]というテーブルを書くかのどちらかであり、認証が必要なサーバーだけcodex mcp loginを追加で実行する、という流れに集約される。

この記事では、公式ドキュメントの記述に沿って、MCPサーバーの2つの接続方式（STDIOとStreamable HTTP）、CLIコマンドの使い方、config.tomlで指定できるオプションの一覧、OAuth認証の仕組み、プラグインが提供するMCPサーバーの扱い、そして実際によく使われるMCPサーバーの例までを整理する。ChatGPTデスクトップアプリやIDE拡張との設定共有についても触れるので、Codex CLI単体だけでなく複数のクライアントを使い分けている場合の参考にしてほしい。

MCP（Model Context Protocol）とは何か｜Codexにおける位置づけ

MCP（Model Context Protocol）とは、モデルをツールやコンテキストに接続するための共通のプロトコルのことです。

公式ドキュメントの冒頭には「ChatGPT webはプラグインが提供するリモートのMCPツールを使える。ローカルのCodexクライアントはMCPサーバーへ直接接続でき、設定を共有できる」と書かれている（Model Context Protocol）。つまりMCPには、ChatGPT web側でプラグイン経由の遠隔ツールとして使う経路と、Codex CLIやIDE拡張・デスクトップアプリからローカルの設定ファイルで直接サーバーへつなぐ経路の2通りがある。この記事が扱うのは、後者のローカルCodexクライアントからの接続方法になる。

ドキュメントはさらに「ChatGPTデスクトップアプリ、Codex CLI、IDE拡張は同じCodexホスト向けのMCPサーバーをサポートし、MCP設定を共有する」と説明している。1回どこかのクライアントでMCPサーバーを設定すれば、別のクライアントに切り替えても設定をやり直す必要はない。提供形態そのものの違い（CLI・IDE拡張・クラウド・アプリ）を先に整理したい場合は、OpenAI Codexの提供形態の違い｜CLI・IDE・クラウド・アプリ比較を先に読んでおくと本記事の前提がつかみやすい。

MCPサーバーが提供するのは実質的に「モデルが呼び出せる外部ツール」であり、この考え方はAPI経由でモデルに外部関数を呼ばせるfunction callingと近い。両者の違いは、function callingが自分のアプリケーションコード内で関数を定義するのに対し、MCPは共通プロトコルに従う独立したサーバープロセスとして外部ツールを用意する点にある。API側の設計手順はOpenAI APIのFunction callingの使い方と設計手順で確認できる。

Codexが対応するMCPサーバーの種類｜STDIOとStreamable HTTP

Codexが対応するMCPサーバーの種類とは、ローカルプロセスとして起動するSTDIOサーバーと、URL経由でアクセスするStreamable HTTPサーバーのことです。

本記事冒頭で引用した公式ドキュメントの「Supported MCP features」には、対応する機能として次の内容が列挙されている。STDIOサーバーはコマンドで起動するローカルプロセスで、環境変数を渡せる。Streamable HTTPサーバーはアドレスでアクセスするサーバーで、bearerトークン認証、Client ID Metadata Documents（CIMD）とDynamic Client Registration（DCR）を含むOAuth認証、信頼済みの第一者サーバー向けのChatGPTセッション認証に対応する。加えて、サーバーが初期化時に返すinstructionsフィールドをCodexが読み取り、サーバー全体のガイダンスとして使う「Server instructions」という仕組みもある。

どちらの方式を選ぶかは、ツールの実体がどこにあるかで決まる。ローカルのファイルシステムやローカルで動くCLIを操作したいツールはSTDIOに向き、社内SaaSやFigmaのようにインターネット越しのサービスを操作するツールはStreamable HTTPに向く。

種類	起動方法	主な認証手段
STDIOサーバー	ローカルプロセスとしてコマンドで起動	環境変数の受け渡し
Streamable HTTPサーバー	URL経由でアクセスするリモートサーバー	bearerトークン／OAuth（CIMD・DCR含む）／ChatGPTセッション認証
プラグイン提供のMCPサーバー	インストールしたプラグインのマニフェストに同梱され、プラグイン側から起動	プラグインのマニフェストで宣言（.mcp.jsonでOAuth設定も可能）

公式ドキュメントは、MCPサーバーの設定がCodexのconfig.tomlに保存され、既定では~/.codex/config.tomlだが、プロジェクトに絞ったMCPサーバーを.codex/config.tomlに置くこともできる（信頼済みプロジェクトに限る）としている。config.toml全体の優先順位や読み込み場所の基本はCodex CLIのconfig.toml完全ガイド｜設定の優先順位と書き方にまとまっている。

codex mcp addコマンドでMCPサーバーを追加する手順

codex mcp addとは、CLIからSTDIO型のMCPサーバーをCodexの設定に登録するためのコマンドのことです。

公式ドキュメントに示されたコマンドの基本形は次のとおり。

codex mcp add <server-name> --env VAR1=VALUE1 --env VAR2=VALUE2 -- <stdio server-command>

具体例として、ドキュメントは開発者向けドキュメントに接続できる無料のMCPサーバーであるContext7を追加する例を挙げている。

codex mcp add context7 -- npx -y @upstash/context7-mcp

コマンドの構造は、サーバーに付ける名前（この例ではcontext7）、--envで渡す環境変数、--の後ろにサーバーを起動する実際のコマンドを並べる形になっている。このコマンドを実行すると、対応する[mcp_servers.context7]のテーブルがconfig.tomlへ書き込まれ、以後はCLIでもIDE拡張でもデスクトップアプリでも同じ設定が読み込まれる。

OAuth対応のリモートサーバーを事前登録済みのクライアントIDで追加したい場合は、--urlと--oauth-client-idを組み合わせて指定できる。この場合Codexは、認可サーバー側に登録すべきコールバックURLを実行結果として表示する。認証の詳しい流れは後述の「OAuth認証のコールバックURLはどう決まるか」で扱う。

mcp list・mcp login・mcp –helpなど主要CLIコマンド一覧

主要CLIコマンドとは、追加済みMCPサーバーの確認・認証・ヘルプ表示に使うcodex mcpのサブコマンド群のことです。

追加以外の操作は次のコマンドでまかなえる。設定済みのサーバー一覧を見るにはcodex mcp listを、利用できる全コマンドを確認するにはcodex mcp --helpを、OAuth対応サーバーの認証をやり直すにはcodex mcp login <server-name>を、それぞれ実行する。

コマンド	用途
codex mcp add <name> -- <command>	STDIOサーバーを追加する（--envで環境変数も指定可能）
codex mcp list	設定済みのMCPサーバー一覧を表示する
codex mcp login <name>	OAuth対応サーバーの認証を開始する
codex mcp --help	利用できるMCPコマンドの一覧を表示する
/mcp（Codex TUI内）	ターミナルUI上で現在有効なMCPサーバーを確認する

公式ドキュメントは、codexコマンドを実行したときのターミナルUI（TUI）の中でも/mcpと入力すると、アクティブなMCPサーバーを確認できるとしている（Model Context Protocol）。ChatGPTデスクトップアプリの場合はコマンドではなく、設定画面から「MCP servers」を開き、composer欄に/mcpと入力して接続済みサーバーを見る操作になる。IDE拡張も同様に歯車メニューから「MCP servers」を開く設定画面が用意されている。

config.tomlでMCPサーバーを設定する基本書式

config.tomlでMCPサーバーを設定する基本書式とは、[mcp_servers.<server-name>]というテーブルの中にサーバーごとのキーを書き並べる形式のことです。

より細かい制御をしたい場合は、codex mcp addを使わず~/.codex/config.tomlやプロジェクト単位の.codex/config.tomlを直接編集する。公式ドキュメントは、サポートされるMCPオプションの一覧はConfiguration Referenceで検索できるとしたうえで、各MCPサーバーは[mcp_servers.<server-name>]というテーブルで設定すると説明している。

Context7をconfig.tomlで直接設定する場合の例は次のようになる。

[mcp_servers.context7]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["LOCAL_TOKEN"]

[mcp_servers.context7.env]
MY_ENV_VAR = "MY_ENV_VALUE"

このように、STDIOサーバーには起動コマンドと引数を、必要なら環境変数を書く。次の2つの節では、STDIOサーバーとStreamable HTTPサーバーそれぞれで使えるキーを、公式のConfiguration Referenceに沿って一覧にする。

STDIOサーバーのconfig.tomlオプション一覧

STDIOサーバーのconfig.tomlオプションとは、ローカルプロセスとして起動するMCPサーバーの起動コマンドや環境を指定するキーのことです。

キー	必須/任意	説明
command	必須	サーバーを起動するコマンド
args	任意	サーバーに渡す引数
env	任意	サーバー用に設定する環境変数
env_vars	任意	ローカル環境から許可して転送する環境変数名のリスト
cwd	任意	サーバープロセスを起動する作業ディレクトリ
experimental_environment	任意	remoteを指定すると、利用可能な場合にリモートのexecutor環境経由でstdioサーバーを起動する

env_varsは文字列だけでなく、ソースを指定したオブジェクトも渡せる。公式ドキュメントの例は次のとおりで、文字列指定とsource = "local"はCodexのローカル環境から読み込み、source = "remote"はリモートのexecutor環境から読み込む（remoteはリモートMCP stdioを使う場合に限る）と説明されている。

env_vars = ["LOCAL_TOKEN", { name = "REMOTE_TOKEN", source = "remote" }]

実務では、APIキーのような秘密情報をenvにベタ書きせず、env_varsでOS側の環境変数を明示的に許可してから使う書き方のほうが、config.tomlをGit管理下に置いたときに秘密情報が混ざりにくい。

Streamable HTTPサーバーのconfig.tomlオプション一覧

Streamable HTTPサーバーのconfig.tomlオプションとは、URL経由でアクセスするMCPサーバーの接続先や認証方法を指定するキーのことです。

キー	必須/任意	説明
url	必須	サーバーのアドレス
auth	任意	設定済みのbearerトークンや認可ヘッダーの後に試す認証方式。既定はoauth（保存済みのMCP OAuth認証情報を使う）で、信頼済みの第一者ChatGPTオリジンに対してはchatgptで現在のChatGPTセッションを使い、失敗時は保存済みOAuthにフォールバックする
bearer_token_env_var	任意	Authorizationヘッダーに載せるbearerトークンを取り出す環境変数名
http_headers	任意	ヘッダー名と固定値のマップ
env_http_headers	任意	値を環境変数から取得するヘッダー名のマップ
http_headers_helper	任意	ヘッダー名と値のJSONオブジェクトを出力するローカルコマンド。ローカル接続のHTTP MCPだけに対応し、stdioサーバーやリモート実行環境経由の接続には使えない

Figmaのリモートサーバーをbearerトークンで設定する例は次のとおりで、固定ヘッダーの指定も同時に行っている。

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }

公式ドキュメントは、http_headers_helperで取得したヘッダーをCodexが接続ごとにキャッシュし、同一オリジンへのPOSTが401か403を返した場合に一度だけヘッダーを再取得して、値が変わっていたときだけ再試行すると説明している（Model Context Protocol）。明示的なbearerトークンやOAuth認証情報は、helperが返すAuthorizationヘッダーより優先される。また、権限不足を示すOAuthの403応答はヘッダー再取得のトリガーにはならない。

タイムアウト・有効化・ツール承認モードなど共通オプション

共通オプションとは、STDIOサーバーとStreamable HTTPサーバーの両方に使える、待ち時間やツールの公開範囲・承認方法を制御するキーのことです。

公式のConfiguration Referenceには、接続方式に関わらず両方のサーバー種別に共通して使えるキーがまとめられている（OpenAI公式 Configuration Reference、2026年9月24日取得）。主なキーと既定値・説明は次のとおり。

キー	既定値	説明
startup_timeout_sec	10秒	サーバーの起動を待つタイムアウト
tool_timeout_sec	60秒	1回のツール実行を待つタイムアウト
enabled	true	falseにすると設定を残したままサーバーを無効化する
required	false	trueにすると、この有効化済みサーバーが初期化できない場合に起動自体を失敗させる
enabled_tools / disabled_tools	未指定（全許可）	公開するツールの許可リストと、許可リスト適用後に効かせる拒否リスト
default_tools_approval_mode	auto	このサーバーのツールに適用する既定の承認挙動。auto・prompt・writes・approveから選ぶ
tools.<tool>.approval_mode	サーバー既定を継承	特定ツールだけ承認モードを個別に上書きする
tools.<tool>.output_token_limit	モデル既定の出力トークン予算	標準20%のシリアライズ許容の前段階で適用される、特定ツールの出力トークン予算
mcp_optional_startup_grace_ms	1,000ミリ秒	初期ツールカタログを組み立てる際、必須でないMCPサーバーの起動をまとめて待つ時間。0にすると各サーバーのstartup_timeout_secいっぱいまで待つ

default_tools_approval_modeのwritesは、読み取り専用と分類されていないツールにだけ確認を挟む挙動になる。書き込み系だけ慎重にしたい場合に使いやすい設定で、公式ドキュメントも「writesモードは読み取り専用として印が付いていないツールにプロンプトを出す」としている。

Chrome Developer ToolsのMCPサーバーで、ツールごとに承認モードや出力上限を個別調整する例は次のとおり。

[mcp_servers.chrome_devtools]
url = "http://localhost:3000/mcp"
enabled_tools = ["open", "screenshot"]
disabled_tools = ["screenshot"] # enabled_toolsの後に適用される
default_tools_approval_mode = "prompt"
startup_timeout_sec = 20
tool_timeout_sec = 45
enabled = true

[mcp_servers.chrome_devtools.tools.open]
approval_mode = "approve"
output_token_limit = 30000

この例ではenabled_toolsでopenとscreenshotを許可したうえで、disabled_toolsでscreenshotだけを後から除外しているため、実際に使えるのはopenのみになる。許可リストと拒否リストは同時に使え、拒否リストが最後に効く点を覚えておくと設定ミスを避けやすい。

OAuth認証のコールバックURLはどう決まるか

OAuthコールバックURLとは、MCPサーバーの認可サーバーがログイン後にCodexへ処理を戻すために使うリダイレクト先のことです。

認可サーバーが事前登録済みのOAuthクライアントを要求する場合、codex mcp addにクライアントIDを渡すと、Codexは登録すべきコールバックURLをそのまま表示する。表示されたコールバックはconfig.tomlのクライアントIDと合わせて保存され、次回以降のログインにも使われる。

codex mcp add example --url https://mcp.example.com --oauth-client-id my-client

[mcp_servers.example]
url = "https://mcp.example.com"

[mcp_servers.example.oauth]
client_id = "my-client"
callback_url = "http://127.0.0.1/callback"

実際にどのコールバックが使われるかは、クライアントIDの有無と、認可サーバーが「issuerパラメータをサポートしているか」の組み合わせで変わる。公式ドキュメントの説明を要点だけ整理すると、次のようになる（Model Context Protocol）。

設定パターン	認可サーバーのissuer対応	実際に使われるコールバック
client_idを設定していない	対応している	設定したcallback_urlがそのままクライアント登録に使われる
client_idを設定していない	対応していない	設定したcallback_urlの末尾にサーバー固有のコールバックIDが付加される
client_idとcallback_urlを両方設定済み	対応している	設定したcallback_urlを再利用し、認可レスポンスのissuerが一致するか検証する
client_idのみ設定（callback_urlは未設定）	対応・非対応いずれでも	mcp_oauth_callback_url（未設定時は既定値）にサーバー固有のコールバックIDを付加して使う

ポート番号を含まないhttp://127.0.0.1形式のコールバックについては、Codexが表示・保存の時点ではリスナーのポートを省き、認可の実行時に実際に使うポートを差し込む。この差し替えはlocalhost表記やIPv6ホスト、HTTPS URL、すでにポートを含むコールバックには適用されない。カスタムのコールバックポートを固定したい場合は、全体に効くmcp_oauth_callback_url・mcp_oauth_callback_portか、サーバー単位のmcp_servers.<name>.oauth.callback_portで上書きできる。Codexは、返されたissuerが登録内容と一致しない場合、認可コードの交換を行わず処理を打ち切る。

OAuthクライアント登録方式｜CIMDとDCRの違い

CIMDとDCRとは、MCPサーバーの認可サーバーに対してOAuthクライアントを自動登録するための、Codexが対応する2つの方式のことです。

公式ドキュメントは、CodexがOAuth Client ID Metadata Documents（CIMD）とDynamic Client Registration（DCR）の両方をサポートすると説明している。既定の挙動は、認可サーバーがclient_id_metadata_document_supported: trueを示し、token_endpoint_auth_methods_supportedにnoneを含み、コールバックが対応済みのループバックURLである場合に自動でCIMDを選ぶというものだ。それ以外の場合はDCRが利用可能ならDCRを使う。config.tomlに設定済みのOAuthクライアントIDがあれば、そちらが常に優先されクライアント登録自体をスキップする。

CIMDを使う場合、CodexはMCPサーバーごとにChatGPTがホストするメタデータドキュメントを利用する。

https://chatgpt.com/oauth/codex/<callback_id>/client.json

公式ドキュメントによれば、共有される安定版のCIMDドキュメント（https://chatgpt.com/oauth/codex/client.json、共有の/callbackパスを使う）は開発中で近日提供予定とされている。カスタムのコールバックホスト・パス・クエリパラメータを使いたい場合は、DCRか設定済みのOAuthクライアントIDが必要になる。

1回のCLIログインだけ登録方式を指定したい場合は、次のように--oauth-client-registrationを使う。この指定はそのログインだけに適用され、config.tomlには保存されない。

codex mcp login <server-name> --oauth-client-registration cimd
codex mcp login <server-name> --oauth-client-registration dcr

プラグインが提供するMCPサーバーの扱い方

プラグイン提供のMCPサーバーとは、インストールしたプラグインのマニフェストに同梱され、プラグイン自身が起動するMCPサーバーのことです。

公式ドキュメントは「インストール済みのプラグインは、プラグインマニフェストにMCPサーバーを同梱できる。こうしたサーバーはプラグイン側から起動されるため、ユーザー側の設定はトランスポートのコマンドを設定しない」と説明している（Model Context Protocol）。ユーザー側から制御できるのは、有効・無効の切り替えとツールの扱いだけで、plugins.<plugin>.mcp_servers.<server>の下に書く。

[plugins."sample@test".mcp_servers.sample]
enabled = true
default_tools_approval_mode = "prompt"
enabled_tools = ["read", "search"]

[plugins."sample@test".mcp_servers.sample.tools.search]
approval_mode = "approve"

プラグイン提供のHTTP MCPサーバーは、.mcp.json側でOAuth設定を宣言することもできる。プラグインマニフェストではキー名がキャメルケースになり、clientId・callbackUrl・callbackPortという表記になる。

{
  "mcpServers": {
    "sample": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "oauth": {
        "clientId": "my-pre-registered-client",
        "callbackUrl": "http://127.0.0.1/callback/registered"
      }
    }
  }
}

プラグイン提供のMCPサーバーも、他のMCPサーバーと同じコールバック選択ルールに従う。プラグインのoauth.callbackPortは全体設定のmcp_oauth_callback_portより優先され、どちらも未設定ならCodexは一時的なポートを選ぶ。

企業導入の文脈では、どのプラグインとツールを使えるかをワークスペース管理者が制御できる点も重要になる。ChatGPT web側の運用と合わせて、利用状況や支出の管理体制を整えたい場合はOpenAI ChatGPT Enterprise向けに利用分析と支出管理を強化｜2026年の最新情報が参考になる。組織全体でのCodex導入手順はOpenAI Codex企業導入ガイド｜モデル・コスト・移行計画・2026年の最新情報にまとまっている。

代表的なMCPサーバーの例｜用途別に見る

代表的なMCPサーバーとは、公式ドキュメントが実際に使えるものとして紹介している、用途の異なる複数のMCPサーバーのことです。

公式ドキュメントは「MCPサーバーの一覧は増え続けている」と前置きしたうえで、よく使われるものとして次のサーバーを挙げている（Model Context Protocol）。

サーバー	用途
OpenAI Docs MCP	OpenAI開発者ドキュメントの検索・閲覧
Context7	最新の開発者ドキュメントへ接続する
Figma（Local／Remote）	自分のFigmaデザインにアクセスする
Playwright	Playwrightを使ってブラウザを操作・検査する
Chrome Developer Tools	Chromeを操作・検査する
Sentry	Sentryのログにアクセスする
GitHub	gitコマンドだけでは扱えないPRやIssueの管理などGitHubを操作する

用途で分けると、ドキュメント参照系（OpenAI Docs MCP・Context7）、開発ツール操作系（Figma・Playwright・Chrome Developer Tools）、開発フロー管理系（Sentry・GitHub）の3系統に大まかに分類できる。最初に触るなら、追加コマンドが1行で済み無料で使えるContext7が試しやすい。プロダクト機能としてはChatGPTのカスタムGPTがアクション経由で外部サービスを呼び出す仕組みと近い発想であり、GPTsとの違いを比較したい場合はカスタムGPT(GPTs)の作り方｜設定・活用・公開手順を解説・2026年の最新情報も参考になる。

仮の例: Context7とFigmaのMCPサーバーをCodex CLIに追加する

この節は、公式ドキュメントに示された設定例だけを使って、STDIOとStreamable HTTPを1つずつ追加する仮の例です。

ここからは仮の例であり、実在の環境設定を前提にしたものではない。題材は、開発ドキュメント検索用のContext7（STDIO）と、デザインファイル参照用のFigma（Streamable HTTP）を、同じCodex CLI環境に追加する場面を想定する。

まずContext7をコマンド1行で追加する。

codex mcp add context7 -- npx -y @upstash/context7-mcp

次に、Figmaはbearerトークンで認証するリモートサーバーのため、config.tomlに直接テーブルを書く。FIGMA_OAUTH_TOKENという環境変数にトークンを設定したうえで、次のブロックを~/.codex/config.tomlに追加する。

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

設定後はcodex mcp listを実行し、context7とfigmaの両方が一覧に出るかを確認する。codexのTUIを使っている場合は、セッション中に/mcpと入力すればアクティブなサーバーをその場で確認できる。もし別のサーバーでOAuthログインが必要になった場合は、この後にcodex mcp login <server-name>を実行する流れになる。

この仮の例では、開発ドキュメントを調べる作業とFigmaのデザインを参照する作業の両方を、同じCodexセッション内でツール呼び出しとして行えるようになる。実際に使うサーバーやトークンの管理方法は、自社のセキュリティ方針に合わせて選んでほしい。

Codex CLIでMCP連携を始める前のチェックリスト

MCP連携を始める前のチェックリストとは、サーバーを追加する前に決めておくと設定のやり直しを減らせる確認項目のことです。

ここまでの内容を踏まえ、実際に手を動かす前に確認しておきたい項目を整理する。

• 接続方式はSTDIOかStreamable HTTPか。ローカルコマンドで動くツールかリモートのURLで提供されるサービスかを先に確認する
• 設定を書く場所はユーザー単位の~/.codex/config.tomlか、プロジェクト単位の.codex/config.tomlか。後者はそのプロジェクトを信頼済みにしている場合だけ読み込まれる
• 認証方式は不要か、bearerトークンか、OAuthか。OAuthならCIMD・DCR・設定済みクライアントIDのどれを使うかも決める
• ツールの承認モードをauto・prompt・writes・approveのどれにするか。書き込み系ツールだけ慎重にしたいならwritesが候補になる
• enabled_tools・disabled_toolsで公開するツールを絞る必要があるか。外部サーバーほど許可リストで絞る判断がしやすい
• 起動やツール実行が遅い場合に備えてstartup_timeout_sec・tool_timeout_sec・mcp_optional_startup_grace_msをどう調整するか

この6項目を先に決めてからcodex mcp addやconfig.tomlの編集に入ると、認証方式の選び直しやツール許可リストの後付けといった手戻りを減らせる。ChatGPTのプロジェクト機能でファイルや指示を整理する運用と組み合わせている場合は、ChatGPTのプロジェクト機能の使い方｜ファイル・指示・チャットの整理手順も参考になる。MCPツールの出力をそのまま後工程で扱いたい場合は、レスポンスの形式を固定するOpenAI APIの構造化出力の使い方｜JSON Schemaで固定する手順も合わせて確認しておくとよい。

よくある質問（FAQ）

Q1. MCPサーバーはCodex CLI・ChatGPTデスクトップアプリ・IDE拡張で別々に設定する必要がありますか。

公式ドキュメントは「ChatGPTデスクトップアプリ、Codex CLI、IDE拡張は同じCodexホストのMCPサーバーをサポートし、MCP設定を共有する。1度MCPサーバーを設定すれば、それらのクライアントを設定し直さずに切り替えられる」と説明しています。config.tomlを1回設定すれば、どのクライアントからでも同じMCPサーバーが使えます。詳細は本記事冒頭で引用した公式ドキュメントを確認してください。

Q2. ChatGPT webでも、ローカルに追加したMCPサーバーを使えますか。

使えません。公式ドキュメントは「ChatGPT webはローカルのCodex設定ファイルを読み込まず、ローカルのCodexコマンドメニューも公開しない」と明記しています。ChatGPT web（Work）でMCP相当のツールを使うには、プラグインをインストールしてその接続先・ツールを使う形になり、どのプラグインを使えるかはワークスペース管理者が制御できます。

Q3. プロジェクト単位の.codex/config.tomlに書いたMCPサーバーは、そのフォルダを開けばすぐ有効になりますか。

いいえ。公式ドキュメントは、MCPサーバーの設定は既定で~/.codex/config.tomlに保存され、プロジェクトにスコープしたMCPサーバーを.codex/config.tomlに置くこともできるが、それは信頼済みプロジェクトに限られるとしています。信頼済みとして扱っていないプロジェクトでは、そのフォルダの設定は読み込まれません。

Q4. OAuth認証が必要なMCPサーバーを追加したら、次に何をすればいいですか。

codex mcp login <server-name>を実行してMCP OAuthログインを開始します。事前登録済みのOAuthクライアントを使う場合は、codex mcp add実行時に--oauth-client-idでクライアントIDを渡すと、Codexが登録すべきコールバックURLをその場で表示します。1回のログインだけ登録方式（CIMDかDCRか）を指定したい場合は--oauth-client-registrationオプションを使います。

Q5. MCPサーバーのツール呼び出しを、毎回確認してから実行したい場合はどう設定しますか。

config.tomlのdefault_tools_approval_modeを調整します。公式ドキュメントによれば値はauto・prompt・writes・approveの4種類で、読み取り専用と分類されていないツールだけ確認したい場合はwritesを選べます。特定のツールだけ挙動を変えたい場合はtools.<tool>.approval_modeで個別に上書きできます。

Q6. MCPサーバーの起動が遅くてタイムアウトする場合はどう調整しますか。

既定10秒のstartup_timeout_secを伸ばすほか、複数のMCPサーバーを並行して起動する際に初期ツールカタログの構築をまとめて待つ時間であるmcp_optional_startup_grace_ms（既定1,000ミリ秒）を0にすると、各サーバーのstartup_timeout_secいっぱいまで待つ挙動に変えられます。requiredをtrueにしているサーバーは、この待ち時間設定に関わらず自身のタイムアウトを使います。

まとめ

Codex CLIのMCP連携は、STDIOかStreamable HTTPかという2つの接続方式を軸に理解すると設定がぶれにくくなる。ローカルコマンドで動くツールはcodex mcp addで1行追加でき、リモートのHTTPサービスはconfig.tomlに[mcp_servers.<server-name>]のテーブルを書いてurlと認証キーを指定する。どちらの方式でも、設定はChatGPTデスクトップアプリ・Codex CLI・IDE拡張の3クライアントで共有される。

認証まわりは、bearerトークンとOAuthの使い分け、OAuthの中でもCIMDとDCRという2つのクライアント登録方式、そしてコールバックURLがクライアントIDとissuer対応の有無で変わる点が要点になる。迷ったらまずauthやbearer_token_env_varを試し、事前登録が必要な認可サーバーに当たったときだけ--oauth-client-idやCIMD/DCRの指定に進む、という順序で十分なケースが多い。

運用面では、enabled_tools・disabled_toolsによるツールの絞り込みと、default_tools_approval_modeによる承認モードの設定が、外部のMCPサーバーを安全に使うための実質的な制御点になる。書き込み系だけ確認を挟みたい場合はwritesモードから試すとよい。設定項目やコールバックの挙動は更新される可能性があるため、本番運用に入る前に公式のModel Context ProtocolとConfiguration Referenceで最新のキーと既定値を確認してほしい。