codex mcp-server非推奨後の移行先｜App Server・SDK・Claude Code pluginの選び方

先に結論：移行先は外部clientの役割で選ぶ

OpenAIの2026-08-24リリースノートは、`codex mcp-server` commandをdeprecatedとし、Codex app serverの利用を案内しています。Claude CodeへCodexを統合する場合はCodex pluginを使う方向も案内されています。ただし、これは一つのMCP設定を別名へ置き換える話ではありません。Codexを外部clientへ組み込んでいた側が、rich client、job / CI、Claude Codeという利用面ごとに移行先を選ぶ記事です。

App ServerはMCP serverではない

Codex App Server Docsは、rich clientがCodexのthreadやイベント、approvalなどを扱うためのJSON-RPC-likeな統合面として説明しています。MCPはAI clientと外部tool / data serverを接続するprotocolです。どちらもtoolという単語を使いますが、message schema、lifecycle、認証、client側の責任が同じとは限りません。`codex mcp-server`からApp Serverへ移す際に、MCP server用の設定やtool listをそのままApp Serverのclient実装へ貼り付けないでください。

現行protocolとtransportを先に固定する

現行App Server Docsは、wire上で`jsonrpc` headerを省いたJSON-RPC 2.0 messageを使うと説明しています。既定のstdioはnewline-delimited JSON、WebSocketは1 message / text frame、Unix socketはHTTP Upgradeを使う別transportです。旧MCP requestをそのまま送らず、選んだCodex versionから生成したTypeScript / JSON Schemaとclient実装を揃えます。

App Serverを選ぶ場合：rich clientの状態を設計する

外部アプリからCodexを操作し、thread表示、進捗、approval、複数ターン、差分確認まで持たせたいならApp Serverを候補にします。移行前に、旧commandが返していた入力・出力・終了状態・stderr・session IDを記録し、App Serverのrequest / notification / eventと対応づけます。Docsに例があるtransportでも、対象version、process lifecycle、認証、切断時の再接続を自分のclientで確認してください。

• 旧commandの入力、出力、exit code、session、approval、ログをfixtureにする
• App Serverのrequest / response / event、thread ID、turn ID、tool approvalを対応表にする
• clientが切断・再接続・二重送信したときのidempotencyと停止条件を決める
• loopback、認証、TLS、process owner、workspace、filesystem、networkの境界を本番前にレビューする
• codex app-server commandとWebSocketのproduction制約を運用文書に残し、代替transportとrollbackを準備する

SDKを選ぶ場合：jobs / CIの証拠をコードに残す

定期job、CI、backend workerのように対話UIより再現可能な実行を重視するなら、App Serverを自前で制御するよりSDKを候補にします。App Server DocsもjobsやCIではSDKを使う方向を示しています。SDK version、非対話認証、timeout、budget、出力schema、retry、artifact、ログの扱いを固定し、CIの成功ステータスだけで外部変更の安全性を証明しないでください。

Claude Code pluginを選ぶ場合：MCP設定と配布面を分ける

Claude CodeへCodexを組み込みたい場合は、release noteが案内するClaude Code pluginを候補にします。PluginはSkills、Hooks、MCP serverなどをまとめて配布できる一方、インストールscope、marketplaceの信頼、更新、削除、pluginが追加するtoolの権限を伴います。Claude Code側でMCPを使う場合も、pluginそのものと、pluginが提供するMCP serverを別々に監査します。

• 誰がpluginをインストールし、user / project / managedのどのscopeへ入れるか決める
• pluginが含むSkills、Hooks、MCP server、外部credential、書き込み権限を一覧にする
• 更新前後のplugin manifest、tool namespace、許可・拒否設定、ログを比較する
• Claude Codeのpermission modeとCodex側のapproval / sandboxを同じ安全境界だと扱わない
• アンインストール、disable、credential revoke、旧integrationへの切り戻しをfixtureで確認する

移行手順：外部client側のownerが先に棚卸しする

• 1. `codex mcp-server`を呼んでいるscript、desktop integration、plugin、CI、serviceを検索し、呼び出し側と設定ownerを記録する
• 2. process transport、stdin / stdout、session、event、exit code、approval、filesystem、network、credentialの境界を表にする
• 3. rich clientはApp Server、jobs / CIはSDK、Claude Code内はpluginという仮説で、既存要件との不足を洗い出す
• 4. read-onlyのfixtureでthread、tool、差分、失敗、切断、再試行を比較し、実装versionと確認日を記録する
• 5. feature flagまたは対象workspaceの限定から切り替え、ログ・diff・test・承認を人間が確認する
• 6. 異常時は外部clientの呼び出しを止め、credentialをrevokeし、未処理sessionを保全してからrollbackする

既存のCodex MCP設定記事との役割分担

既存の「CodexのMCP設定ガイド」は、Codex hostへ外部MCP serverを登録するconfig.toml、CLI、Desktop、IDE、OAuth、tool policyを主に扱います。このページは、外部clientがCodexを呼んでいた`codex mcp-server`側の移行先を扱います。両方を一つの記事へ混ぜず、MCP protocolの設定とApp Server / SDK / pluginの統合を別のownerとしてリンクします。