Slack pluginが認証できない原因と対処 — Claude CodeのOAuthエラー

Claude CodeでSlack pluginを認証しようとすると、ブラウザが開かないまま失敗することがあります。エラーは「Incompatible auth server: does not support dynamic client registration」です。Slack側のOAuthサーバーが動的クライアント登録(DCR)を受け付けないため、Claude Codeはv2.1.30以降で、事前登録したクライアントIDを渡す方法を用意しました。

Slack pluginの認証がDCRエラーで失敗する仕組み

/pluginや/mcpからSlackを認証すると、次のようなエラーが出て失敗します。

MCP server "plugin:slack:slack": No client info found
MCP server "plugin:slack:slack": SDK auth error: Error: Incompatible auth server: does not support dynamic client registration
MCP server "plugin:slack:slack": SSE Connection failed: Non-200 status code (404)

Claude CodeはMCPサーバーへOAuth接続する際、まず動的クライアント登録(DCR)を試みます。DCRはRFC 7591の仕組みで、クライアントIDを認可サーバー側に自動発行させます。Slackのサーバーはこの自動登録に対応していません。これがエラーの正体です。

公式ドキュメントも同じ文言を挙げ、このエラーが出たサーバーは事前設定済みの認証情報を必要とすると説明しています。GitHub issue #18009は2026年1月13日にv2.1.6で起票され、8月19日にクローズされるまでの約7か月間に20件のコメントが付きました。

同じエラー文言の裏にあった別々の原因

issueが長引いたのは、原因が1つではなかったからです。起票時のログは次のとおりで、プラグインのバージョンやエンドポイントが後の報告と異なります。

Claude Code version: 2.1.6
Plugin: slack@claude-plugins-official
Server URL: https://mcp.slack.com/sse

コメント欄に出てきた原因は、時期ごとに層が違います。

エラー文言が同じでも、直し方は層ごとに違います。以降は、どの層を疑うかの順に書きます。

バージョンによる対処の違い

Claude Code側では、複数のバージョンで関連する修正が入っています。

v2.1.30がSlackを例に挙げて事前設定クライアント資格情報を追加し、最初の壁を越えられるようになりました。ただしv2.1.229で127.0.0.1が使われ、厳密一致を求めるサーバーでサインインが通らなくなっています。v2.1.229で失敗した場合について、changelogはアップグレードするか、サーバー側の登録済みリダイレクトURIにhttp://127.0.0.1:PORT/callbackを足すよう案内しています。

v2.1.231で、v2.1.229で起きた不一致は解消しています。登録済みのリダイレクトURIとポートが食い違っていれば、v2.1.231以降でも同じ不一致になります。

更新しても直らないときの切り分け

まず手元のバージョンと、claude mcp addが受け付けるオプションを見ます。以下の出力はv2.1.289のものです。

claude --version
claude mcp add --help

claude mcp add --helpには、事前登録クライアント向けのオプションが次の説明で並びます。

--callback-port <port>   Fixed port for OAuth callback (for servers requiring pre-registered redirect URIs)
--client-id <clientId>   OAuth client ID for HTTP/SSE servers
--client-secret          Prompt for OAuth client secret (or set MCP_CLIENT_SECRET env var)
-t, --transport <transport>  Transport type (stdio, sse, http). Defaults to stdio if not specified.

次に、Slackを公式pluginで使っているか、自分で.mcp.jsonに書いているかで対処が分かれます。

プラグインキャッシュが古い版のまま残っている

issueの4月15日のコメントによると、マーケットプレイスはSlack pluginの取得元をhttps://github.com/slackapi/slack-mcp-plugin.gitに切り替えました。新しい構成はhttps://mcp.slack.com/mcpエンドポイントとクライアントIDを持ちます。旧エンドポイントについては、Slackの開発者ドキュメントがリクエストの送り先をhttps://mcp.slack.com/mcpとし、SSEベースの接続には対応していないと書いています。既存のインストールは旧版のキャッシュを使い続け、DCRを試みて失敗します。症状には、エラーなしで再起動後にSlackが消える型もあるとのことです。プラグインの取得元や更新の仕組み自体はClaude Codeプラグイン完全ガイドにまとめています。

コメントの手順は、マーケットプレイスの更新と、Slack pluginのキャッシュ削除です。

git -C ~/.claude/plugins/marketplaces/claude-plugins-official pull origin main
rm -rf ~/.claude/plugins/cache/claude-plugins-official/slack/

そのうえで~/.claude/settings.jsonに"enabledPlugins": {"slack@claude-plugins-official": true}が残っているかを見ます。残っていればClaude Codeを再起動します。Slack pluginが新しいエンドポイントで取得し直されます。6月26日には、~/.claude/.credentials.jsonのSlack MCPの項目を削除して直ったという別の報告もあります。キャッシュ削除で直らないときの追加の手がかりです。

独自にSlack MCPサーバーを設定している

公式pluginではなく.mcp.jsonやclaude mcp addで自分でSlack MCPサーバーを追加している場合は、事前登録済みのOAuthクライアント情報を明示します。手順は、Slack開発者ポータルでOAuthアプリを登録し、クライアントIDとコールバックポートを渡す形です。Slackの開発者ドキュメントでは、MCPを使えるのはSlack Marketplaceに公開されたアプリと社内アプリだけで、非公開のまま外部に配布するアプリは使えません。SlackのMCPクライアントはconfidential OAuth(秘密を持つクライアントの認証)に対応しており、アプリのclient_idとclient_secretを使います。登録フォームでリダイレクトURIを求められたら、空きポートを選んでhttp://localhost:PORT/callbackと入力し、同じポートを--callback-portに渡します。

claude mcp add --transport http \
  --client-id your-client-id --client-secret --callback-port 8080 \
  slack-mcp https://mcp.slack.com/mcp

--client-secretはクライアントシークレットをマスク入力で尋ねます。CIではMCP_CLIENT_SECRET環境変数で渡せます。クライアントシークレットを持たない公開クライアントなら、--client-secretを省いて--client-idだけを渡します。

クライアントシークレットはmacOSではキーチェーンに、それ以外では資格情報ファイルに保存され、設定ファイルには残りません。クライアントシークレットを渡せるのはaddのときだけです。あとから付け足すなら、claude mcp remove <name>で消して、同じスコープで--client-secret付きで追加し直します。

JSONで定義したいときは、claude mcp add-jsonにoauthオブジェクトを渡します。

claude mcp add-json slack-mcp \
  '{"type":"http","url":"https://mcp.slack.com/mcp","oauth":{"clientId":"your-client-id","callbackPort":8080}}' \
  --client-secret

認証は、Claude Codeで/mcpを開いてブラウザのログインに進みます。SSH先などブラウザを開けない環境ではclaude mcp login slack-mcp --no-browserが認可URLを表示し、リダイレクト先のURLを貼り戻す形で完了できます。ここで紹介した--client-idなどのフラグは、HTTPとSSEのトランスポートにだけ効き、stdioのサーバーには効きません。

OAuthメタデータの自動検出そのものが誤動作している

先述のissuer不一致が直るとは限りません。標準の検出先が使えないサーバーや社内プロキシ経由にしたいときは、authServerMetadataUrlで参照先のメタデータURLを固定できます。.mcp.jsonのoauthオブジェクトに書き、URLはhttps://で始める必要があります。

通常は、RFC 9728のProtected Resource Metadataを/.well-known/oauth-protected-resourceで調べます。次にRFC 8414の認可サーバーメタデータへフォールバックします。authServerMetadataUrlはこの検出の流れを飛ばす逃げ道です。固定したURLのscopes_supportedは、サーバー側が示すスコープより優先されます。

スコープを絞りたい、または別のエラーに変わった

does not support dynamic client registrationとは異なるno_bot_scopes_requestedのようなエラーに変わることがあります。issueのクローズコメントは、この場合をSlackアプリの設定側の問題と整理しています。要求するスコープを自分で固定するには、oauth.scopesにスペース区切りの文字列を書きます。ドキュメントの例はSlackで、次のようになっています。

{
  "mcpServers": {
    "slack": {
      "type": "http",
      "url": "https://mcp.slack.com/mcp",
      "oauth": {
        "scopes": "channels:read chat:write search:read"
      }
    }
  }
}

oauth.scopesはauthServerMetadataUrlやサーバーが示すスコープより優先されます。固定したスコープが足りず、あとからinsufficient_scopeの403が返ったときは、ツール呼び出しが失敗して/mcpに認証が必要と表示されます。スコープを足して/mcpから認証し直さないと、新しいトークンにも同じ不足が残ります。

v2.1.196以降は、oauth.scopesを指定しない場合、サーバーがWWW-Authenticateヘッダーや保護リソースメタデータで示したスコープだけを要求します。以前は自動検出したメタデータのscopes_supportedを全部要求していたため、管理者専用のスコープに当たるとinvalid_scopeで拒否される事例がありました。

VS Code拡張のv2.1.81では、MCPパネルの表示が「Needs Auth」のままでも、Slackのツール自体は動いているという報告がコメントにあります。パネルの表示だけで判断せず、実際にSlackを操作するツールを呼び出して確かめると切り分けが早くなります。

自前のヘルパーでAuthorizationを付けている

headersHelperでAuthorizationを供給するサーバーでは、v2.1.248より前は、ヘルパーが渡した資格情報の拒否を報告せずOAuthの探索を走らせることがありました。その結果、DCRのエラーが出ます。エラー解説に載っている現象です。v2.1.248以降は、401を受けるとヘルパーを再実行して呼び出しを再試行します。Slack pluginの失敗とは別の経路なので、headersHelperを使っているサーバーだけがこのケースに当たります。

DCR非対応はSlack以外のSaaSでも起きる

動的クライアント登録に対応していない認可サーバーは、Slackに限った例外ではありません。issueの5月15日のコメントは、Slack・Google Workspace・HubSpot・Microsoft Graph・Salesforceを並べています。いずれも開発者ポータルで事前登録したクライアントIDを使う運用だという指摘です。MCPの実装がDCRを標準の認証手段として想定する一方、企業が実務で使いたいSaaSほどDCRに対応していない、というねじれが起きやすい構図です。

v2.1.30で追加された--client-id・--client-secretは、Slack以外の自前MCPサーバーがDCR非対応のときにも使えます。v2.1.81で追加されたCIMD(Client ID Metadata Document)対応は、DCRを使わない別の登録方式のサーバーが対象で、自動で見つけて使われます。

公式pluginとは別の経路でSlackにつなぎたい場合は、Slack MCPサーバーの使い方のボットトークン方式という選択肢もあります。こちらはユーザーではなくボットの権限で動くため、ボットをチャンネルへ個別に招待する運用が前提です。

まとめ

エラー文言が同じでも、疑う層は構成によって変わります。まずClaude Codeがv2.1.231以降かを見て、そのうえで公式pluginか自前定義かで、キャッシュと事前登録クライアントのどちらを疑うかが分かれます。