Codex利用時のMCPサーバーの認可設定
こんにちは、ナカエです。 前回の NextatでのAI活用状況 に引き続き、AI活用ブログ記事シリーズの第二弾です。
弊社ではAIによる開発支援のためCodexなどのAIエージェントツールを活用しています。業務でCodex などのAIエージェント経由でMCPサーバーを利用する際は、認可はほぼ必須です。混同されがちですが、ID確認を行う「認証（Authentication）」ではなく、リソースへのアクセス権を設定する「認可 (Authorization)」が適切です。
MCP公式でも、認可の仕様の議論が行われています。
参考： Authorization - Model Context Protocol
本記事では、Codexの設定ファイル（~/.codex/config.toml）でMCPの認可を設定する方法を見ていきます。
※ 以下はCodex CLI 0.50.0で検証した内容になります。
Codex CLIのMCPの認可設定例
1. ローカルMCPサーバー（認可なし）
Serena を使う場合の設定が下記です。 Serenaは uv を使ってローカルで起動するのが一般的です。起動に時間がかかることがあるので、起動時のタイムアウトを設定しています。
[mcp_servers.serena]
command = "uvx"
args = [
"--from",
"git+https://github.com/oraios/serena",
"serena",
"start-mcp-server",
"--context",
"codex",
]
startup_timeout_sec = 30
2. リモートMCPサーバー（アクセストークンによる認可）
2-1. プロキシー利用
Codex 0.46.0より前のバージョンではCodexのMCPサーバー接続のトランスポートは標準入出力しかサポートされていなかったため、mcp-proxy などの標準入出力のトランスポートをHTTP+SSE（現在非推奨）やStreamable HTTPに変換してくれるプロキシーを利用する必要がありました。
HTTPのAuthorizationヘッダーにGitHubのPersonal Access Token（以下PAT）をBearerトークンとして設定することで認可を行います。コーディングエージェントがMCPを使って読み書きする権限はPATの発行時に設定することになります。
[mcp_servers.github]
command = "mcp-proxy"
args = [
"--transport",
"streamablehttp",
"-H",
"Authorization",
"Bearer {GitHubのPAT}",
"https://api.githubcopilot.com/mcp/",
]
参考： CodexとGitHubのリモートMCPサーバを接続する
2-2. 直接接続
0.46.0 でHTTPストリーミングを使うリモートMCPサーバーがサポート されたので現在（0.50.0）は下記のように書けます。 experimental_use_rmcp_client = true を設定する必要があります。
experimental_use_rmcp_client = true
[mcp_servers.github]
url = "https://api.githubcopilot.com/mcp/"
bearer_token_env_var = "GITHUB_TOKEN"
GitHubのPAT（Personal Access Token）はconfigファイルではなく環境変数に逃すことが簡単にできるようになりました。 GitHub側のMCPサーバーの認可の方法としては、AuthorizationヘッダによるBearerトークンで 2-1. と同じです。
3. リモートMCPサーバー（OAuth 2.1ベース）
AtlassianのMCPサーバー（Rovo MCP Serverと呼称される）への接続を例に挙げます。
MCP公式の認可の仕様 は OAuth 2.1やOAuth 2.0の拡張仕様をベースとしています。OAuth2.1自体もIETF DRAFTとして議論中なので確定するのは少し先になりそうです。OAuth 2.1はPKCEを必須とし脆弱なフローを廃止するなど、OAuth 2.0に比べてセキュリティ面が改善されています。 標準的でセキュアなOAuth2.1への準拠により、MCPの認可における利用側のセキュリティ設計・判断の負担が軽減されます。
Rovo MCP Serverも現在ベータ版ですがOAuth 2.1をベースとしており、この認可の仕様に準拠することを想定していると思われます。
3-1. プロキシー利用
プロキシーとして利用する mcp-remote をnpxで起動しています。
[mcp_servers.atlassian]
command = "npx"
args = [
"-y",
"mcp-remote",
"https://mcp.atlassian.com/v1/sse",
]
startup_timeout_sec = 30
3-2. 直接接続
下記のように簡単に設定できるようになるはずですが、現在のところCodex起動時にMCP接続に失敗するので 3-1.のプロキシーの設定を利用しています。
experimental_use_rmcp_client = true
[mcp_servers.atlassian]
url = "https://mcp.atlassian.com/v1/sse"
上記を設定した上でCodexを起動する前に、明示的にログインさせる仕様となっているようです。
$ codex mcp login atlassian
このコマンドを実行するとブラウザに遷移してユーザーが認可の操作を行います。
ログインコマンド自体は成功しているのですが……
$ codex mcp login atlassian
Authorize `confluence` by opening this URL in your browser: https://mcp.atlassian.com/v1/authorize?（略）
Successfully logged in to MCP server 'atlassian'.
その後のCodexの起動時にエラーが出てしまいました。
$ codex
# （略）
■ MCP client for `confluence` failed to start: handshaking with MCP server failed: Send message error Transport [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<rmcp::transport::auth::A uthClient<reqwest::async_impl::client::Client>>>] error: Client error: HTTP status client error (404 Not Found) for url (https://mcp.atlassian.com/v1/sse), when send initialize request
CodexのGitHub Issueにも同じ問題は報告されており、AtlassianのMCPサーバーが非推奨となったHTTP+SSEのトランスポートを利用しているのが原因のようです。 Atlassian側のHTTPストリーミング トランスポートへの対応を待つのが良さそうです。
参考： https://github.com/openai/codex/issues/4707#issuecomment-3420373089
また、Codex 0.50.0の時点ではOAuthに対応していないGitHubのMCPサーバー設定に対しても警告が出るなど、CodexのMCP認可対応自体にも今後改善されるであろう箇所が見受けられます。
■ The github MCP server is not logged in. Run `codex mcp login github`.
今後の想定
現状IDとパスワードを使う認可（というより認証）を独自に提供しているMCPサーバーなどもあるようですが、今後はMCP公式の認可の仕様に合わせていくものと思われます。
公式がリモートのMCPサーバーを提供している場合はそちらを認可込みで優先的に使うことになるだろうと考えており、最終的には下記に落ち着く想定でいます。
- リモートのリソースに依存しない場合は、ローカルのMCPサーバーを認可なしで利用
- MCPサーバー実装の安全性については別途確認が必要
- リモートのリソースへのアクセスを提供する公式MCPサーバーに対してはOAuth 2.1に準拠したMCP公式の認可を利用して直接接続
- ローカルで起動するMCPプロキシーの役目はなくなっていくはず
- リモートのリソースに対してサードパーティのMCPサーバーしか提供されていない場合はその実装を検証して利用
