GitHub MCPサーバーにOAuth接続できないエラーの原因と対処

Claude Codeでclaude mcp add --transport http github https://api.githubcopilot.com/mcp/のようにGitHubのリモートMCPサーバーを追加し、/mcpからOAuthで認証しようとすると、「Incompatible auth server: does not support dynamic client registration」というエラーで接続が失敗する報告が続いています。2025年7月に登録されたGitHub Issue #3433として追跡されている既知の問題で、原因はGitHub側の認可サーバーがDynamic Client Registration(DCR)に対応していないことにあります。本記事では原因の切り分けと、Claude Code側のバージョンごとの対応状況を含めた実際に通る対処法を、GitHubのリモートMCPサーバーに絞って扱います。リモートMCPのOAuth認可フローの一般的な仕組みはリモートMCPのOAuth認証にまとめてあるので、あわせて参考にしてください。

GitHubのリモートMCPサーバーで何が起きるか

GitHubのリモートMCPサーバーとは、GitHubがホストするMCPエンドポイント(https://api.githubcopilot.com/mcp/)です。Issueやプルリクエストの操作を、Claude Codeから自然文の指示で呼び出せます。

現行のClaude Codeで問題が起きるのは、OAuthで接続しようとしたときだけです。ヘッダーなしでclaude mcp add --transport http github https://api.githubcopilot.com/mcp/を実行し、/mcpパネルから認証を試みると、Claude Codeは次のエラーを返します。

Error: Incompatible auth server: does not support dynamic client registration

Issueの本文には、同じ設定がVS Codeでは動作すると記載されています。原因はGitHub側の設定ミスではなく、Claude CodeのOAuthクライアントとGitHubの認可サーバーの組み合わせにあります。

Issueのコメントには、Anthropic APIを使う環境だけでなくAWS Bedrock経由でも同じエラーが起きるという報告があります。Claude Codeのバージョンでは、最初の報告があったv1.0.51から、2026年1月に報告が続いたv2.1.6・v2.1.7まで一貫して再現しており、特定のバージョンだけの不具合ではありません。Claude Code側の対応状況は後述します。

エラーの原因はDCR非対応

Claude CodeがリモートMCPサーバーへOAuth接続するとき、まずクライアントIDを認可サーバーに登録する必要があります。この登録方式の1つがDynamic Client Registration(DCR)です。クライアントがPOST /registerを呼ぶだけで、認可サーバーが自動的にclient_idを発行してくれる仕組みです。

GitHubのMCP認可サーバーはこのDCRに対応していません。Issueのコメントでも「GitHubがDCRをサポートすれば解決するはず」と指摘されています。事前登録クレデンシャルもCIMDでの自動発見も使わない標準のOAuthサインインでは、Claude CodeがDCRでの自動登録を試み、認可サーバーから登録自体を拒否されてエラーになる、という構図です。

表示されるエラー文言ごとの原因と対処

ログでは、エラー文言の前にSDK auth error: Error:が付くことがあります。見分けるときは末尾の文言を見ます。

当たる行によって、次に読む節が変わります。1行目ならこのあとのPATか--client-idの節へ進みます。

PATをヘッダーで渡せば接続できる

Claude Codeのドキュメントは、GitHubのリモートMCPサーバーの接続例としてOAuthではなく、GitHubのPersonal Access Token(PAT)をヘッダーで渡す方法を案内しています。GitHubの個人アクセストークン設定で、対象リポジトリへのアクセス権を持つfine-grainedトークンを発行し、次のように追加します。

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
  --header "Authorization: Bearer YOUR_GITHUB_PAT"

claude mcp addはトークンの有効性を検証せずに設定を保存するため、追加コマンド自体が成功しても、実際の呼び出しで失敗することがあります。/mcpを実行し、githubがconnectedと表示されるかを確認します。認証情報が誤っている場合はfailedと表示され、失敗の詳細で、GitHub側の応答を確かめられます。

ヘッダーを付けたかどうかで、失敗の出方が変わります。エラー文言から、どちらの状態で接続しているかを逆算できます。

Issueのコメントでも、Authorizationヘッダーにトークンを渡す同じ方法が回避策として共有され、複数の利用者が「これで動いた」と追認しています。最初に共有された回避策は--headerフラグではなくclaude mcp add-jsonでheadersオブジェクトを直接書く形でしたが、Claude Codeへ渡る設定内容は同じです。複数のヘッダーを同時に設定したい場合や、設定をJSONで一元管理したい場合はadd-jsonの形が向いています。トークンの発行手順や、有効にするtoolsetsの絞り方、read-onlyモードとの併用はGitHub MCPサーバーの使い方にまとめてあります。

マーケットプレイスのgithubプラグインを使う場合の落とし穴

/pluginからインストールできるマーケットプレイスのgithubプラグインは、内部の.mcp.jsonが環境変数GITHUB_PERSONAL_ACCESS_TOKENからトークンを読み込む設定になっています。ところが/mcpや/pluginのパネルには「Authenticate」ボタンが表示され、押すとOAuthサインインが始まり、claude mcp addを手動で行った場合と同じ「Incompatible auth server」エラーで失敗します。同じプラグインには、環境変数が展開されずHTTP 400で失敗する別の既知issueもあります。詳しくはGitHub MCPプラグインがHTTP 400で失敗する原因と対処で扱っています。

対処は環境変数を設定することで、ボタンを押す必要はありません。Issueのコメントには、macOS・Windowsの両方でこの手順を踏んで解決した報告が複数あります。

export GITHUB_PERSONAL_ACCESS_TOKEN="YOUR_GITHUB_PAT"

変数名はGITHUB_PERSONAL_ACCESS_TOKENである必要があります。GITHUB_PATやGITHUB_TOKENという名前で設定しても、プラグインの.mcp.jsonはその変数を参照しないため接続できません。設定後はターミナルを再起動してからClaude Codeを開き、/mcpでconnectedになっているかを確認します。

client IDを事前登録してOAuthのまま接続する方法

Claude Codeはv2.1.30で、DCRに対応しない認可サーバー向けに、事前登録したクレデンシャルを--client-idと--client-secretで渡す機能を追加しました。同じ「Incompatible auth server」エラーが出ていたSlackのリモートMCPサーバーのIssue(#18009)は、このv2.1.30の機能追加と、続くv2.1.231のリダイレクトURIミスマッチ修正をもってクローズされています。実際にSlack接続が直った決め手は、Slackのプラグイン側がエンドポイントを切り替え、事前登録済みのクライアントIDを組み込んだことです。DCR前提の実装では動かないサービスに対し、あらかじめ発行済みのclient_idをプラグインに同梱する対応でした。なおv2.1.81では、DCRに代わる新しい仕組みであるClient ID Metadata Documents(CIMD)の自動発見にも対応していますが、これはSlackの解決とは別の変更です。

事前登録の流れは次のとおりです。Claude Code v2.1.285のclaude mcp add --helpには、--client-id、パスワード入力式の--client-secret、固定ポートを指定する--callback-portが並んでいます。

v2.1.229だけは、リダイレクトURIをhttp://127.0.0.1:PORT/callbackで送るため、localhostで登録したサーバーがURIの不一致で拒否します。v2.1.231でlocalhostに戻っています。

GitHubのリモートMCPサーバーでも、この事前登録の経路は使えます。Issue #3433のコメントには、GitHubで自分のOAuth Appを登録し、コールバックURLをhttp://localhost:4321/callbackにする方法が共有されています。追加コマンドは次の形です。

claude mcp add --transport http --client-id YOUR_CLIENT_ID --client-secret \
  --callback-port 4321 github https://api.githubcopilot.com/mcp/

投稿者自身は「動くはず」という書き方で、AnthropicやGitHubの公式手順ではありません。翌日には別の利用者が「これが解決策だ」と応じています。GitHub側の認可サーバーがCIMDに対応しているかは確認できていないため、Claude Codeをv2.1.81以降に更新するだけで直るとは言い切れません。手順の一般形はリモートMCPのOAuth認証で扱っています。

Issue #18009のコメントでは、この制約はGitHubやSlackに限らず、Google Workspace・HubSpot・Microsoft Graph・Salesforceのような業務SaaSにも共通するという指摘があります。投稿者が理由に挙げたのは、これらのサービスが開発者ポータルで事前登録したアプリのclient_idとclient_secretを要求し、DCRでの自動登録を用意していない点です。GitHub Enterprise Serverなど、社内ホスト型の環境で同じエラーが起きるかどうかは、Issue #3433上では報告されておらず判断材料がありません。

ローカルサーバーとghコマンドという別の経路

OAuthでサインインしたいなら、GitHubが配布するローカルのDockerサーバー(ghcr.io/github/github-mcp-server)に切り替える方法があります。github.com向けの公式イメージにはアプリのクレデンシャルが同梱されており、初回利用時にブラウザーでログインするだけで済みます。トークンはメモリ上にのみ保持されます。今回のDCR非対応問題は、Claude Codeがリモートのhttps://api.githubcopilot.com/mcp/へOAuthクライアントを登録しようとする経路で起きるもので、ローカルサーバーは認証の仕組み自体が異なります。設定手順はGitHub MCPサーバーの使い方にまとめてあります。

Issueのコメントでは、MCPサーバー自体を使わず、Bashツール経由でghコマンドを直接呼ばせる案も共有されています。事前にgh auth loginでサインインしておけば、Issueの作成やPRのレビューはMCPサーバーを介さずに実行できます。

Issue #3433が起票されてからの経緯

GitHub APIで確認したところ、Issue #3433は最後の更新が2026-06-30で、状態はopenのままです。コメント上には、GitHub側がDCRやCIMDに対応した、あるいはGitHubが組み込みクライアントIDを用意したという報告は見当たりません。

まとめ

経路は4つあります。PATをヘッダーで渡す、プラグインなら環境変数を設定する、自前のOAuth Appを事前登録する、ローカルのDockerサーバーに切り替える、の4つです。トークンを設定に置きたくないか、OAuthで入りたいかで選べます。GitHub以外のサーバーを含む接続不具合の切り分け手順はMCPサーバーに接続できないときの切り分け手順で扱っています。