CodexのMCP設定方法は？接続方式別の手順とつながらない時の対処法

codex mcp addで登録したはずのMCPサーバーが、Codexに出てこないまま止まっていませんか。

原因の多くは、設定ファイルの書き方かコマンドの解決に絞られます。どこを見ればよいかわからないまま書き換え続けると、動かない状態が長引きます。

MCPは、Codexから外部ツールやデータを操作するための共通規格です。本記事では、登録の手順からトークンの渡し方、つながらないときの対処法まで解説します。

読み終えるころには、接続方式に合った登録のしかたを選び、つながらないときも症状から原因をたどれるようになります。まずは3つの接続方式から確認していきましょう。

MCPをつなぐのは、Codexに任せられる作業を増やすためです。

つなぎ先を増やしても、指示を出すのが自分のままでは手を動かす量は変わりません。

ただし、記事を読んで分かったつもりのままでは、自分の手作業で全部こなす状態は明日も変わりません。

SHIFT AIでは、AIエージェント無料セミナーを週2回ほど開催しています。CodexかClaude Codeを自分のPCで動かすまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。

CodexのMCPは3つの接続方式で設定手順が変わる

CodexのMCPには、登録のしかたが異なる3つの接続方式があります。

この3つを取り違えると、登録したはずのサーバーがCodexから見えないままになります。

ローカル（stdio）：codex mcp addで登録する

手元のPCで動かすMCPサーバーは、codex mcp addコマンド1行で登録できます。

stdioは、Codexがサーバーを子プロセスとして起動し、標準入出力でやり取りする方式です。通信が手元のPCの中で完結するため、外部にデータが出ていきません。

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

「–」より前がCodexへの指示、後ろがサーバーの起動コマンドです。ファイル操作やドキュメント参照など、多くのMCPサーバーがこの方式で配布されています。

設定ファイルを開かずに済むため、1本目のMCPサーバーはこの方式から試すと迷いません。

リモート（Streamable HTTP）：codex mcp addに–urlでURLを渡す

クラウド上で動くMCPサーバーは、--urlにURLを渡して登録します。

--urlと起動コマンドは同時に指定できません。URLを渡した時点で、Streamable HTTPのサーバーとして登録されます。

codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT

Streamable HTTPは、URLに対してHTTPでやり取りする方式です。認証はトークンかOAuthで行うため、stdioにはない項目が増えます。

起動コマンドを渡すかURLを渡すかだけの違いなので、覚えることは多くありません。

プラグイン：MCPサーバーが同梱され自分では登録しない

プラグインを使う場合は、MCPサーバーを自分で登録する必要がありません。

プラグインはMCPサーバーを自身のマニフェストに同梱でき、そのサーバーはプラグイン側から起動されるためです。ユーザーが起動コマンドを書く場所がそもそもありません。

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

config.tomlで指定できるのは、有効にするかどうかや使わせるツールの範囲だけです。画面から追加して認証する使い方で足りるなら、プラグインのほうが手数は少なくなります。

逆に、配布されていないサーバーを自分でつなぎたい場合は、この後のcodex mcp addとconfig.tomlの手順が必要です。

Codexのプラグイン自体の入れ方とおすすめの選び方は、以下の記事で画面操作の手順から解説しています。

【3ステップ】codex mcp addでローカルMCPサーバーを登録する手順

ローカルのMCPサーバーは、3つのステップで登録から確認まで完了します。

ここではObsidianのメモをCodexから読み書きできるようにする例で、3つのステップを順に見ていきます。

ステップ1：登録するサーバーの起動コマンドを確認する

最初に、そのMCPサーバーがどのコマンドで起動するかを配布元で確認します。

codex mcp addは起動コマンドをそのまま受け取って登録するだけで、コマンドの正しさは検証しないためです。ここが違っていると、登録は成功したように見えて後から起動に失敗します。

• Node.js製のサーバー：npxで起動するものが多い
• Python製のサーバー：uvxで起動するものが多い
• APIキーが要るサーバー：環境変数の名前もあわせて確認する

Obsidianの場合は、先にObsidian側でコミュニティプラグインの「Local REST API」を有効にし、発行されたAPIキーを控えておきます。

Codex CLIの導入がまだの場合や料金プランを確認したい場合は、Codex本体の使い方を先に押さえておくとつまずきません。

ステップ2：codex mcp addでObsidianの名前とコマンドを登録する

起動コマンドがわかったら、サーバー名と起動コマンドをcodex mcp addに渡します。

サーバー名はCodexの中でそのサーバーを指す識別子です。あとから設定を確認したり削除したりするときに使うため、短くわかりやすい名前を付けます。

codex mcp add <サーバー名> --env 変数名=値 -- <起動コマンド>

APIキーが必要なサーバーは、--envで環境変数として渡します。ObsidianのMCPサーバーであれば、ステップ1で控えたAPIキーをここで指定します。

codex mcp add obsidian --env OBSIDIAN_API_KEY=控えたAPIキー -- uvx mcp-obsidian

「–」の位置を間違えると起動コマンドがCodexへのオプションとして解釈されるため、区切りの位置だけは必ず確認してください。

ステップ3：codex mcp listで登録できたか確認する

登録したら、codex mcp listで一覧に出るかどうかを確認します。

addが成功していても、起動コマンドが誤っていればCodexを起動した時点で読み込みに失敗します。登録の成否と起動の成否は別物なので、一覧で登録内容を目視して確かめます。

codex mcp list

一覧にサーバー名と起動コマンドが表示されれば、設定ファイルへの書き込みは成功しています。実際にツールが呼べるかどうかは、Codexを起動して確認します。

ここまでで、手元のMCPサーバーをCodexから使う準備が整いました。

config.tomlの[mcp_servers]でCodexのMCPを制御する3つの設定項目

config.tomlを直接編集すると、codex mcp addでは指定できない項目まで設定できます。

設定ファイルは、macOSとLinuxでは~/.codex/config.tomlに置かれています。

http_headers：リモートサーバーに独自ヘッダーを足す

独自のヘッダーを求めるリモートサーバーは、http_headersをconfig.tomlに書き足します。

codex mcp add --urlで指定できるのは、URLと認証まわりのオプションまでだからです。それ以外の項目は、保存されたエントリへ直接書き足します。

[mcp_servers.example]
url = "https://example.com/mcp"
http_headers = { "X-Region" = "ap-northeast-1" }

環境変数から値を取りたい場合は、env_http_headersという項目も用意されています。認証トークンの渡し方だけは別の項目を使うため、あとでまとめて解説します。

OAuthで認証するサーバーであれば、登録後にcodex mcp loginでブラウザ認証を通します。

startup_timeout_sec：起動が遅いサーバーの待ち時間を延ばす

起動に時間がかかるサーバーは、startup_timeout_secで待ち時間を延ばします。

この項目の既定値は10秒です。npxやuvxで初回にパッケージをダウンロードするサーバーは、この10秒に収まらず読み込みに失敗することがあります。

[mcp_servers.playwright]
command = "npx"
args = ["-y", "@playwright/mcp@latest"]
startup_timeout_sec = 30
tool_timeout_sec = 120

ツール1回あたりの待ち時間はtool_timeout_secで、こちらの既定値は60秒です。ブラウザ操作のように1回の処理が長いサーバーは、両方を見直します。

数値を延ばすほど異常時の待ち時間も伸びるため、必要な分だけ広げるのが現実的です。

enabled_tools：使うツールだけに絞る

サーバーが公開するツールは、enabled_toolsで使うものだけに絞れます。

MCPサーバーは書き込みや削除まで含めた多くのツールを公開することがあります。すべてを有効にしたままだと、意図しない操作をCodexが選ぶ余地が残ります。

[mcp_servers.example]
enabled_tools = ["search", "read"]
disabled_tools = ["delete"]

disabled_toolsはenabled_toolsのあとに適用される拒否リストです。読み取り系だけを許可しておくと、試している段階で事故が起きません。

config.tomlにはMCP以外にも、使うモデルや承認の出し方などの設定項目があります。ファイル全体の書き方と設定項目は以下の記事で解説しています。

【3ステップ】CodexのMCPをプロジェクトごとに切り替える手順

Codexは、プロジェクトごとに別々のMCP設定を読み込めます。

リポジトリごとに使うMCPサーバーが違う場合は、この仕組みで切り替えます。

ステップ1：プロジェクト直下に.codex/config.tomlを作る

プロジェクト単位の設定は、リポジトリ直下の.codex/config.tomlに書きます。

ホームディレクトリの設定はすべての作業に効いてしまうためです。特定のリポジトリでしか使わないサーバーをそこに書くと、関係のない作業でも読み込まれます。

[mcp_servers.serena]
command = "uvx"
args = ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"]

書き方はホーム側のconfig.tomlと同じです。プロジェクト側の設定はホーム側より優先して適用されます。

ただしファイルを置いただけでは読み込まれません。次のステップの承認が必要です。

ステップ2：起動時に信頼済みプロジェクトとして承認する

プロジェクト側の設定は、信頼済みプロジェクトとして承認したときだけ読み込まれます。

これは、リポジトリに置かれた設定ファイルが勝手に実行されるのを防ぐための仕組みです。過去のCodex CLIでは、この承認が無いことを突いた脆弱性が報告されています。

• リポジトリ内の設定ファイルが自動で読み込まれていた
• そこに書かれた起動コマンドが、確認なしで実行されていた

この問題はバージョン0.23.0以前で報告され、現在は承認を求める仕組みで塞がれています。
出典：GitHub Advisory Database（CVE-2025-61260）

承認を求められるのは安全のためなので、身に覚えのないリポジトリでは承認しないでください。中身を確認してから承認すれば、プロジェクト単位の設定を安心して使えます。

ステップ3：config.tomlだけを共有しauth.jsonはGit管理から外す

チームで使う場合は、config.tomlだけをGitに含めます。

.codex/には設定ファイル以外に、認証情報を持つauth.jsonなどが作られることがあるためです。フォルダごとコミットすると、認証情報がリポジトリに入ります。

.codex/*
!.codex/config.toml

.gitignoreでフォルダ全体を除外し、config.tomlだけを対象から外す書き方が扱いやすくなります。APIキーそのものはconfig.tomlにも書かず、環境変数で渡します。

受け取った側は承認するまで設定が読み込まれないため、共有しても勝手に実行される心配はありません。

MCPのトークンを環境変数で渡す4つの方法

MCPサーバーに渡す認証情報には、用途の違う4つの渡し方があります。

どれを選ぶかで、設定ファイルに秘密の値が残るかどうかが変わります。

–env：codex mcp addの実行時に渡す

--envは、登録するときにまとめて環境変数を指定する方法です。

コマンド1行で登録と認証情報の指定が済むため、手数がもっとも少なくなります。変数はいくつでも並べられます。

codex mcp add obsidian --env OBSIDIAN_API_KEY=値 -- uvx mcp-obsidian

ただし、指定した値はconfig.tomlに書き込まれます。手軽ですが、値そのものがファイルに残る点は理解して使う必要があります。

個人のPCだけで完結する用途なら、この方法がもっとも早く動かせます。

env：config.tomlに書く

envは、config.tomlに環境変数を直接書く方法です。

--envで登録した内容も、最終的にはこの形でファイルに保存されます。あとから値を変えたいときは、この項目を書き換えます。

[mcp_servers.obsidian]
command = "uvx"
args = ["mcp-obsidian"]
env = { "OBSIDIAN_API_KEY" = "値" }

注意点は、値が平文で残ることです。このファイルをリポジトリに入れると、トークンがそのまま共有されます。

チームで設定を共有する場合は、次のenv_varsに切り替えると値をファイルから追い出せます。

env_vars：手元の環境変数をそのまま引き継ぐ

env_varsは、値を書かずに変数の名前だけを並べる方法です。

指定した名前の環境変数が、Codexを動かしている環境からMCPサーバーへ引き渡されます。値はシェルの側で管理するため、config.tomlには残りません。

[mcp_servers.obsidian]
command = "uvx"
args = ["mcp-obsidian"]
env_vars = ["OBSIDIAN_API_KEY"]

この書き方なら、config.tomlをそのままGitに入れても値は漏れません。チームで設定を共有するなら、この形が基本です。

使う側は、あらかじめ自分のシェルで同じ名前の環境変数を用意しておきます。

bearer_token_env_var：トークンではなく変数の名前を書く

リモートのサーバーでは、bearer_token_env_varに変数の名前を書きます。

ここでもっとも多い間違いが、トークンの文字列そのものを書いてしまうことです。この項目が受け取るのは値ではなく、値を入れてある環境変数の名前です。

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

この例では、EXAMPLE_TOKENという環境変数に入れた値が認証に使われます。トークンを直接書くと認証に失敗するため、401が出たときはまずここを疑います。

渡し方を使い分けられるようになると、設定ファイルを共有しても認証情報だけ手元に残せます。

うまく使えるようになるほど、自分の手が空かないことが気になってきます。

SHIFT AIの無料オンラインセミナーでは、CodexかClaude Codeを自分のPCで動かすところまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。

CodexのMCPサーバーを確認・管理する4つのコマンド

登録したあとの確認や削除は、4つのコマンドで完結します。

設定を確認する場所と、実際に読み込まれた結果を見る場所が分かれている点が重要です。

codex mcp get：1つのサーバーの設定を確認する

codex mcp getは、指定した1つのサーバーの設定内容を表示します。

一覧では起動コマンドの全体や環境変数までは読み取りにくいためです。設定を書き換えたあと、意図どおりに保存されたかを確かめるときに使います。

codex mcp get obsidian

config.tomlを直接開いて確認する方法もありますが、コマンドならCodexが実際に読み取った内容を確認できます。

設定ファイルを複数持っている場合、どれが効いているかの切り分けにも役立ちます。

codex mcp remove：不要なサーバーを削除する

使わなくなったサーバーは、codex mcp removeで登録を削除します。

MCPサーバーを増やすほど、Codexが毎回読み込むツールの説明も増えます。使っていないサーバーを残しておくと、そのぶん処理が重くなります。

codex mcp remove obsidian

一時的に外したいだけなら、config.tomlのenabledをfalseにする方法もあります。設定を残したまま無効にできるため、あとで戻す前提ならこちらが便利です。

使うサーバーを絞っておくと、動作が軽くなるだけでなく原因の切り分けも簡単になります。

codex mcp login：OAuthで認証を通す

OAuthで認証するサーバーは、codex mcp loginでブラウザ認証を通します。

トークンを自分で発行する代わりに、サービス側の画面で許可を出す方式だからです。登録しただけではツールを呼べず、この認証が必要になります。

codex mcp login <サーバー名>

実行するとブラウザが開き、許可すると認証情報が手元に保存されます。アカウントの権限を超えた操作はできないため、トークンを直接扱うより安全に運用できます。

認証の有効期限が切れた場合も、同じコマンドで通し直せます。

/mcp：セッション中に読み込まれたツールを確認する

Codexを起動したあとは、/mcpで実際に読み込まれたツールを確認します。

設定ファイルに書かれていることと、Codexが起動時に読み込めたことは別だからです。起動に失敗したサーバーは、ここに出てきません。

/mcp

codex mcp listが設定の一覧なのに対して、/mcpは実際に使える状態になっているかの答え合わせです。つながらないときは、まずここを見ます。

ここに出てこない場合の原因の絞り込みは、このあとの症状別の対処法で解説します。

Claude CodeのMCP設定をCodexに読み替える

Claude Codeの設定をそのまま持ってくると、3つの箇所で書き方が変わります。

形式が違うため、設定ファイルをコピーしてもCodexは読み込めません。

キー名：mcpServersではなくmcp_serversと書く

もっとも間違えやすいのが、キー名がmcpServersではなくmcp_serversである点です。

Claude CodeはJSONで書くためキャメルケース、CodexはTOMLで書くためスネークケースになっているからです。見た目が似ているぶん、気づきにくい違いです。

項目	Claude Code	Codex
形式	JSON	TOML
キー名	mcpServers	mcp_servers
起動コマンド	command／args	command／args
環境変数	env	env／env_vars

commandとargsの考え方は共通しているため、書き写す作業自体はそれほど大きくありません。

Claude Code側のMCPの仕組みやおすすめのサーバーは、以下の記事でまとめて解説しています。

設定ファイルの置き場：~/.codex/config.tomlと承認済みプロジェクトを読む

設定ファイルの場所も、ツールごとに別の場所を見ています。

Codexが読むのは、基本的にホームの~/.codex/config.tomlと承認したプロジェクトの.codex/config.tomlです。Claude Code側の設定ファイルは読み込まれません。

• 全体に効かせたい：~/.codex/config.toml
• そのリポジトリだけ：.codex/config.toml（承認が必要）

Codexでは、CLIとデスクトップアプリ、IDE拡張が同じconfig.tomlを共有します。1か所に書けば、どの入り口から使っても同じMCPサーバーが読み込まれます。

移行するときは、まず全体用の1か所に集約してから、必要なものだけプロジェクト側へ移すと整理しやすくなります。

環境変数：値を書かずenv_varsで名前だけ渡す

移行でつまずきやすいのは、環境変数の書き方の違いです。

Claude Code側では値を直接書く形が中心ですが、Codexには値を書かずに名前だけを渡すenv_varsがあります。ここを使い分けないと、移した設定に秘密の値が残ります。

• 値ごと移す：env = { “TOKEN” = “値” }
• 名前だけ移す：env_vars = [“TOKEN”]
• リモートの認証：bearer_token_env_var = “TOKEN”

argsの配列は、JSONとTOMLでどちらも角かっこで書くため、そのまま移せます。変換で手を入れる必要があるのは、キー名と環境変数まわりだけです。

この3点を押さえておけば、Claude Codeで使っていたサーバーをCodexでも同じように動かせます。

CodexのMCPがつながらないときの症状別対処法6つ

MCPがつながらないときは、症状から原因を絞り込めます。

最初に見るのは/mcpで、そこに出るかどうかで原因が大きく2つに分かれます。

program not found：起動コマンドを絶対パスで指定する

program not foundが出る場合は、起動コマンドが見つかっていません。

CodexがMCPサーバーを起動するときの環境は、普段使っているシェルと同じとは限らないためです。シェルでは動くコマンドでも、Codexからは見えないことがあります。

which npx

表示されたパスを、config.tomlのcommandにそのまま書きます。デスクトップアプリから起動した場合はとくに差が出やすいため、絶対パスにすると安定します。

この方法なら、環境の違いに左右されずに同じサーバーを起動できます。

request timed out：起動のタイムアウト上限を引き上げる

request timed outが出る場合は、起動が既定の待ち時間に間に合っていません。

npxやuvxで起動するサーバーは、初回にパッケージをダウンロードするためです。回線の速度によっては、既定の10秒では終わりません。

対処は2つあります。先に手元でパッケージを取得しておくか、待ち時間の上限を延ばすかのどちらかです。

[mcp_servers.example]
startup_timeout_sec = 60

初回だけの問題であれば、一度起動が通ったあとは既定値に戻しても動きます。

/mcpに出てこない：設定ファイルの場所とキー名を見直す

/mcpに何も出てこない場合は、設定ファイルがそもそも読まれていません。

読み込み先は基本的に、ホームディレクトリのconfig.tomlと承認済みプロジェクトのconfig.tomlだからです。別の場所に置いたファイルは無視されます。

• ファイルの場所が~/.codex/config.tomlになっているか
• キー名がmcpServersではなくmcp_serversになっているか
• プロジェクト側に置いた場合、承認を済ませたか

Claude Codeから移してきた設定では、キー名がmcpServersのまま残っていることがよくあります。codex mcp listに出るかどうかで、設定側と起動側のどちらの問題かを切り分けられます。

listに出るのに/mcpに出ない場合は、設定は読めていて起動に失敗している状態です。

認証エラー：トークンを環境変数で渡し直す

認証エラーが返る場合は、トークンの渡し方を取り違えている可能性があります。

とくに多いのが、bearer_token_env_varにトークンの文字列そのものを書いてしまう間違いです。この項目が受け取るのは、値ではなく環境変数の名前です。

• bearer_token_env_varに書いたのが変数名かどうか
• その環境変数が実際に設定されているか
• OAuthのサーバーなら、codex mcp loginを済ませたか

OAuthで認証するサーバーは、登録しただけでは使えません。認証の有効期限が切れている場合も同じエラーになるため、迷ったらloginをやり直します。

環境変数が読めているかは、Codexを起動するシェルで確認しておくと確実です。

Windowsで起動しない：npxではなくnpx.cmdを指定する

Windowsだけ起動しない場合は、コマンドの実体がnpx.cmdである点が原因です。

WindowsのNode.jsはnpxをバッチファイルとして配置しているためです。拡張子まで含めて指定しないと、実行ファイルとして解決されないことがあります。

where npx

表示されたパスを、config.tomlのcommandにそのまま書き写します。macOSやLinuxで動いていた設定をそのまま持ち込むと、この点で止まります。

パスに空白が含まれる場合は、エスケープの書き方もあわせて確認してください。

ツール名が衝突する：登録サーバーを絞る

意図しないツールが呼ばれる場合は、複数のサーバーが似た名前のツールを公開しています。

検索やファイル読み取りのような一般的な機能は、多くのMCPサーバーが持っているためです。数が増えるほど、Codexがどれを選ぶかの判断も難しくなります。

[mcp_servers.example]
enabled_tools = ["search"]

使うツールだけを許可すると、選択肢が減って動きが安定します。使っていないサーバーはenabledをfalseにするか、削除しておきます。

ここまでの6つを順に確認すれば、つながらない原因のほとんどは特定できます。

手順どおりに動かすとき、操作しているのは結局いつも自分です。

SHIFT AIの無料オンラインセミナーでは、CodexかClaude Codeを自分のPCで動かすところまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。

CodexのMCPに関するよくある質問

CodexのMCPに関する質問は以下の5つです。

• MCPとSkillsはどちらを使えばいいですか？
• 配布元が不明なMCPサーバーを登録しても安全ですか？
• 設定ファイルはどこにありますか？
• デスクトップアプリやIDE拡張でも同じ設定が使えますか？
• Codex自体をMCPサーバーとして使えますか？

質問に対する回答を確認して、MCPを導入するときの判断の参考にしてみてください。

MCPとSkillsはどちらを使えばいいですか？

外部のツールやデータに接続したいならMCPを選びます。

MCPはCodexの外にあるサービスと通信するための仕組みだからです。一方のSkillsは、Codex自身の作業手順をまとめておく機能で、通信先を増やすものではありません。

• GitHubのIssueを読ませたい：MCP
• レビューの観点を毎回同じ手順で適用したい：Skills

やりたいことが「外部とつなぐ」ならMCP、「作業のやり方を覚えさせる」ならSkillsと考えると迷いません。SkillsとMCPの違いは、以下の記事で比較しています。

配布元が不明なMCPサーバーを登録しても安全ですか？

MCPサーバーの登録は、配布元が確認できるものだけにしてください。

MCPサーバーを登録するとは、そのプログラムを自分のPCで実行させることだからです。中身によっては、ファイルの読み書きや外部への送信まで実行されます。

• 公式が配布しているか、ソースが公開されているかを確認する
• enabled_toolsで読み取り系だけに絞ってから試す
• 身に覚えのないリポジトリでは、プロジェクト設定を承認しない

最初は権限を絞って動かし、必要になったぶんだけ広げるのが安全な進め方です。

設定ファイルはどこにありますか？

ホームディレクトリの~/.codex/config.tomlにあります。

Codexはユーザーごとの設定をホーム配下にまとめて置く仕組みだからです。OSによってフォルダの表記だけが変わります。

• macOS・Linux：~/.codex/config.toml
• Windows：ユーザーフォルダ内の.codexフォルダ

ファイルが無ければ、自分で作成しても問題ありません。

codex mcp addで登録したときも、書き込まれる先はこのファイルです。手で編集した内容とコマンドで登録した内容は、同じ場所にまとまります。

プロジェクト単位で使う場合だけ、リポジトリ直下の.codex/config.tomlが追加で読まれます。

デスクトップアプリやIDE拡張でも同じ設定が使えますか？

CLIもデスクトップアプリも、同じconfig.tomlを共有します。

次の3つの入り口は、いずれも同じ設定ファイルを読み込む設計になっているためです。

• コマンドラインのCodex CLI
• デスクトップアプリ
• VS Codeなどのエディタ拡張

CLIで登録したMCPサーバーは、デスクトップアプリからもそのまま使えます。使う場所ごとに設定を作り分ける必要はありません。

ただし起動元によってコマンドの探し方が変わるため、CLIでは動くのにアプリでは起動しない場合があります。その場合は、起動コマンドを絶対パスで指定すると解決します。

Codex自体をMCPサーバーとして使えますか？

使えますが、公式では非推奨とされています。

Codexを他のツールから呼ばれる側にするcodex mcp-serverは、公式ドキュメントで非推奨と案内されているためです。代わりにcodex app-serverを使う方針が示されています。

• これから始めるならcodex app-serverを使う
• Claude Codeから呼ぶなら公式のCodexプラグインを使う

本記事で扱うのはCodexにMCPサーバーを登録する側なので、詳細は公式ドキュメントを確認してください。

接続方式の見極めとエラーの切り分けでCodexのMCPを使いこなそう

CodexのMCPは、接続方式によって渡すものが変わります。ローカルのサーバーはcodex mcp addに起動コマンドを渡し、リモートのサーバーは--urlでURLを渡して登録します。

まずは手元で使うサーバーを1つ選び、codex mcp addで登録して/mcpに出るところまで進めてみてください。1本通れば、2本目からは同じ手順の繰り返しです。

MCPをつないで作業が速くなった先で分かれるのは、空いた時間をどの作業に振り向けるかという判断です。任せる範囲を広げるほど、その差は大きくなります。

AIの使いどころが見えても、工程を前に進めるのは自分という点は変わりません。

SHIFT AIの無料オンラインセミナーでは、CodexかClaude Codeを自分のPCで動かすところまで一緒に進めます。以下のボタンから、ご希望の日程を選んでください。