MCP OAuthが毎日Connection expiredになる原因と再接続手順
リフレッシュトークンが有効でもMCPコネクタが毎日「Connection expired」になる報告の整理です。再接続の手順と、サーバー側で確認する点をまとめます。
MCPコネクタが毎朝「Connection has expired. You can reconnect to re-authenticate.」と表示され、Connectを押すと一瞬で直る。これは、リフレッシュトークンが生きているのにクライアントが自動更新を試みない、という報告です。GitHubのissue anthropics/claude-code#65036で40件のリアクションを集めており、未解決のまま報告が続いています。
直し方は、Connectを押す、/mcpでRe-authenticateを選ぶ、claude mcp loginを実行する、のいずれかです。根本の修正が入るまでは、毎回この再接続が必要になる環境があります。
毎日「Connection expired」になる症状とは
issueの報告者は、Microsoft Entraを認可サーバーにしたカスタムHTTP MCPサーバー(OAuth 2.0 + PKCE)で次の流れを再現しています。
- コネクタを追加してConnectし、OAuthを完了する。接続済みになり、ツールも動く
- アクセストークンの期限(約1時間)が過ぎる
- 翌朝、claude.aiやClaude Desktopで「Connection has expired」が出る
- Connectを押すと、約200ミリ秒でログイン画面もMFAもなく再接続できる
4番目が肝です。Entraのサインインログには「MFA requirement satisfied by claim in the token」と残り、リフレッシュトークンの交換が成功した形跡になります。つまりトークン自体は有効で、期限切れの時点で交換が呼ばれていない、という見立てです。
Claudeのログにはエラーも出ません。報告では「401の再試行を記録せずに期限切れ状態へ切り替わる」と書かれています。
どの画面・どの認可サーバーで報告されているか
issueとコメントに出てくる環境を並べると、特定のIdPやOSに限った話ではありません。
| 報告された環境 | 認可サーバー・コネクタ | 備考 |
|---|---|---|
| claude.ai(Web)、Claude Desktop | 認可サーバー・コネクタEntra、Databricks | 備考Databricksは50人超の組織で毎日発生 |
| Claude Cowork(Windows) | 認可サーバー・コネクタEntra、Cognito | 備考Cognitoはアクセストークン24時間、リフレッシュ90日 |
| Claude Code(VS Code拡張) | 認可サーバー・コネクタclaude.aiのアカウントレベルコネクタ | 備考/mcpは接続済みなのにツール呼び出しが失敗 |
| Claude Code(CLI v2.1.259) | 認可サーバー・コネクタtype: httpのリモートMCP | 備考約2時間の長いセッション中に再認可を要求 |
issue本文はAtlassian、Microsoft 365、Google Driveといった提供元側のコネクタも対象に挙げています。ただし、あるコメントはMicrosoft 365では毎日の切断が起きていないとも書いており、構成によって差が出る可能性があります。
何が起きているのか: 報告から見える3つのパターン
原因は確定していません。コメントの証拠は、次の3つに分かれます。
期限が来ても更新リクエストが出ない
CognitoのCloudTrailを添えた報告では、1日目の15時台にrefresh_tokenの交換が200で成功したあと、17時間は更新リクエストも400もなく、翌朝ユーザーがConnectを押した時点でauthorization_codeの交換が走っています。拒否されたのではなく、試していない形です。
更新が一度拒否されると、そのまま止まる
別のコメントは当初「更新を一切しない」と書いたあとで訂正し、クライアントは更新を試みていると述べています。認可サーバー自前運用のログでは、POST /oauth/tokenが200で通った23時間後に400(refresh token expired)になり、その後2日以上、トークンも認可リクエストも来なかったそうです。
この報告の見立てでは、トークンエンドポイントが4xxを返したときに新しい認可リクエストへ進まないことが本当の不具合です。Entraで同じ症状を出した原因としては、委任された権限の付与がなくAADSTS65001で更新が拒否されていた、というサーバー側の理由も挙がっています。
保存時点で期限が過ぎている
Claude Code v2.1.259の報告者は、~/.claude/.credentials.jsonの該当サーバーのexpiresAtが、ファイルの最終更新時刻より約3.5分前だったと書いています。期限切れのトークンを書き込んでいるなら、更新を先延ばしにする以前の問題です。同じ報告者は、同じMCPサーバーをCursorから使うと期限切れが出なかったとも述べています。
3つが同じ原因とは限りません。症状は同じ「期限切れ表示」でも、更新が呼ばれていないのか、拒否されているのかで対処が変わります。
再接続して使い続ける手順
コネクタを復旧させる3つの経路
- 1
claude.ai・Desktop・Coworkのコネクタ
コネクタ一覧のConnectを押します。リフレッシュトークンが残っていれば、ログイン画面なしで戻ります。
- 2
Claude Codeの対話セッション
/mcpを開き、要認証のサーバーでRe-authenticateを選びます。リフレッシュトークンを拒否されたときは、Claude Codeが/mcpを案内する通知を出します。 - 3
シェルから
claude mcp login <名前>で、同じOAuthの流れをコマンドラインから実行できます。SSH先などブラウザがない環境では認可URLが表示され、リダイレクト後のURLを貼り戻す形になります。
シェルからの実行例です。claude.aiのコネクタ名は/mcpの表示名に合わせます。
claude mcp login sentry
claude mcp login sentry --no-browser # ブラウザなし環境一括で失敗サーバーをつなぎ直したい場合は、/mcp reconnect allの使い方にまとめています。
再接続をスキルにする(コメントで共有された工夫)
issueのコメントには、claude mcp loginをスキルから呼ぶ方法が出ています。スキル本文の !`…` 行はモデルに渡る前に実行されるため、呼び出すだけで再ログインが走る、という考え方です。報告者の例を、コネクタ名を差し替える前提で簡略化すると次のようになります。
---
name: connector-login
description: claude.aiのMCPコネクタを再認証する。ツールが
"This connector requires authentication" や401を返したときに使う。
user-invocable: true
---
!`claude mcp login "claude.ai Example MCP" 2>&1 | tail -20`コメントの作者は、親プロセスから引き継がれるCLAUDE_CODE_ENTRYPOINTが認可URLのproduct_surfaceに入り、有効な付与があると同意画面を飛ばして終わる、と述べています。同意をやり直したい場面だけ、env -u CLAUDE_CODE_ENTRYPOINTを前に付ける使い方です。これは個人の観察で、公式のドキュメントには書かれていません。
サーバー運営者が確認する点
自分でMCPサーバーを運用している場合、クライアント側の不具合と切り分けるために、次の点を見ます。
offline_accessが付与されているか。issueの検証では、クライアントはoffline_accessを要求し、Entraも付与していました- 更新リクエストがトークンエンドポイントに届いているか。更新はリソースサーバーを通らず、直接認可サーバーへ飛びます。MCPサーバーのログだけを見ても、拒否と未実行は見分けられません
- 更新が拒否されていないか。Entraでは
oauth2PermissionGrantsに、クライアントとリソースの組の付与があるかを確認する、というコメントがあります - トークンのTTLが短くないか。Databricksの報告では、アクセストークン1440分、リフレッシュトークン43,200分で設定しても毎日発生しており、短いTTLだけでは説明できません
- RFC 8707の
resourceパラメータ。カスタムコネクタは/authorizeにresourceを含め、Microsoft 365のコネクタは含めない、という差を挙げたコメントがあります。更新時の扱いが関係するかは未検証とされています
Claude Codeのドキュメントによれば、認可サーバーのメタデータがoffline_accessを広告している場合、oauth.scopesで固定したスコープにもClaude Codeがoffline_accessを追加し、ブラウザなしで更新できるようにします。
Claude Code側ですでに直った不具合
Claude Code自体のOAuth更新は、これまでに複数の修正が入っています。毎日の再認証が止まらないときは、まずバージョンを確認します。
MCP OAuthの更新まわりの修正
- v2.1.118expires_inのない応答
トークン応答に
expires_inがないMCPサーバーで、1時間ごとの再認証が必要になる問題を修正。 - v2.1.136複数サーバーの同時更新
複数のリモートMCPサーバーが同時に更新するとリフレッシュトークンが失われる問題を修正。変更履歴には、複数サーバーを使う場合の毎日の再認証がなくなるはず、と書かれています。
- v2.1.186claude mcp login追加
claude mcp login <name>とlogoutが追加され、/mcpを開かずに認証できるように。 - v2.1.206一時的な失敗でフラグを立てない
ネットワークエラーなど一時的な理由で更新に失敗しても、有効なリフレッシュトークンがあるのにセッション中ずっと要認証扱いになる問題を修正。
ドキュメントによれば、すでにサインインしたOAuthサーバーが401を返すと、Claude Codeは保存済みのトークンを更新し、再接続して一度だけ再試行します。再試行も失敗したときだけ/mcpに印が付きます。issueの症状は、この経路を通らない場面で起きているようです。
切り分け: どこで切れているか
症状から原因の側を絞る
ローカルで追加したサーバー
claude mcp addや.mcp.jsonのHTTPサーバーです。Claude Codeを最新にし、/mcpでRe-authenticateします。同名のサーバーを複数のスコープで別URLに定義していると、OAuthのサインインはエンドポイントごとに別管理になる点にも注意します。
claude.aiのコネクタ
claude.ai側で保持される認可です。session token rejectedと出る場合は、コネクタの再認証ではなく/loginをやり直します。クラウドセッションのコネクタは、claude.aiのコネクター設定から接続し直します。
MCP server "<name>" session expiredのように、接続済みなのにツール呼び出しだけが失敗する報告もあります。これはトークンの期限切れ表示とは別の状態の可能性があります。VS Codeウィンドウの再読み込みでも直らなかった例があり、その場合は/mcpの再接続操作そのものが使えないこともあるそうです。
GitHubのMCPで初回から接続できない場合は、GitHub MCPのOAuth接続エラーを参照してください。トークン自体の失効はOAuth token revokedの対処、リモートMCPの認証の仕組みはリモートMCPのOAuth認証で扱っています。
回避策の選択肢
リフレッシュの挙動を変える設定キーはありません。ヘッダーを作る仕組みとしては、Claude Codeのローカル設定にheadersHelperがあります。
選べるのは次の3つです。
- 毎日の再接続を受け入れる。Entraでは、サインイン頻度のConditional Accessを180日にすると、再接続がログイン画面なしで済みます
- 再接続をスキルや手順書に落とす(前述)
- Claude Codeに
claude mcp addや.mcp.jsonでローカル追加した自前サーバーで認証方式を選べるなら、headersHelperで短命トークンを生成する。claude.ai・Desktop・Coworkのコネクタには使えず、OAuthにも戻りません
コミュニティ製のstdioブリッジmcp-stdioが、ローカルでリフレッシュトークンを保持して401時に更新する回避策として挙がっています。ただし端末ごとの導入が必要で、リフレッシュトークンを手元の仲介役が扱うことになります。issue内でも、トークンを預ける先の信頼性を問う指摘が出ています。
まとめ
「Connection expired」が毎日出る場合、再接続すれば直るかどうかが最初の分かれ目です。Connectで一瞬戻るなら、リフレッシュトークンは有効で、更新が呼ばれていないか拒否されている状態です。
自前サーバーなら認可サーバーのログで更新リクエストの有無を見ます。Claude Code側のサーバーなら、v2.1.206以降かを確認して/mcpで再認証します。コネクタ側は、issueが閉じるまで再接続が運用の一部になります。