Claude Codeで何度もログインを求められる原因と対処法

Claude Codeが1日に何度も/loginを要求してくる場合、大半は同じ認証情報を複数セッションが同時に使っていることが原因です。OAuthのリフレッシュトークンは1回使うと無効になる仕組みのため、並行して開いた別のセッションが更新済みのトークンを知らないまま古いトークンを提示すると、そこだけ弾かれて再ログインを迫られます。単一セッションでも頻発する場合は、システム時刻のズレやKeychainへの書き込み失敗など、別の原因を疑う必要があります。

この不具合はGitHub Issue #1757で2025年6月から報告が続き、後継のIssue #24317でOAuthリフレッシュトークンの競合という具体的な機構が特定されました。以下では原因の切り分け方と、公式changelogに残る修正の変遷、今すぐ試せる対処法をまとめます。

何度も再ログインを求められる主な原因

症状のパターンから、原因はおおむね次の4つに切り分けられます。

保存されているのはアクセストークンとリフレッシュトークンの2つです。Issue #24317の報告者による調査では、アクセストークンの有効期限は数時間単位、リフレッシュトークンは1回使うと失効する使い捨て方式とされています。複数セッションを並行運用するユーザーほど、この2種類のトークンの更新タイミングが衝突しやすくなります。

保存済みログインそのものの期限切れは、これとは別の話です。公式ドキュメントによると、/loginで作成したログインの期限が近づくと起動時に警告が出ます。この警告はv2.1.203で追加され、v2.1.217以降は期限3日前から表示されます。期限が切れるとLogin expired · Please run /loginというエラーになり、これは日常的な頻発とは区別できる想定内の挙動です。

2025年から続く報告の広がり

Issue #1757は2025年6月に立てられ、以降も断続的にコメントが付いています。報告された環境はWSL2、SSH越しのリモート接続、Ctrl+Cでセッションを中断したあとの再開、ローカルインストールとグローバルインストールを行き来した直後など多岐にわたり、当初は単一の原因に絞り込めていませんでした。OSやインストール方法がまちまちな報告が並存していたこと自体が、この不具合の切り分けを難しくしていた事情です。WSL2ユーザーの多くは同じインスタンス上で3〜4個のセッションを常時起動していたと述べており、後にIssue #24317で特定された並行セッション競合と矛盾しない報告が大半を占めます。一方で、インストール経路の混在やSSH切断時の中断など、競合以外の要因が絡んでいたと見られる報告も残っており、単一の修正だけでは全報告を説明しきれない点には注意が必要です。

OAuthリフレッシュトークンが競合する仕組み

Issue #24317に投稿された分析では、次の流れで競合が起きると説明されています。

1. 複数のClaude Codeプロセス(セッションA・B)が起動時に同じリフレッシュトークンをメモリへ読み込む
2. セッションAのアクセストークンが先に期限切れになり、リフレッシュトークンを使って新しいトークンペアを取得する
3. サーバー側は古いリフレッシュトークンをその時点で無効化し、~/.claude/.credentials.jsonには新しいトークンが書き込まれる
4. セッションBのアクセストークンも期限切れになり、メモリに残ったままの古いリフレッシュトークンを提示する
5. サーバーはすでに使用済みの古いトークンを拒否し、セッションBはブラウザーでの再ログインを求められる

並行して開くセッション数が増えるほど、この衝突が起きる確率も上がります。公式changelogにも、まさにこの現象への対応と読める修正がv2.1.81に記録されています。

バージョン別に見る対策の変遷

公式changelogをOAuthやtoken refreshで追うと、この系統の不具合への対応が複数バージョンに分かれて入っていることが分かります。

v2.1.81でセッション間のロック調整が入ったことで、少数の並行セッションでは競合が大きく減りました。v2.1.248ではロック待ちの扱い自体も改善され、ロックを取れなかった場合に即座に再ログイン画面へ送るのではなく、リトライ可能なエラーとして返すようになっています。

並行数が多いと今も再発する場合がある

Issue #24317には、v2.1.81のロック導入後も、並行セッション数が多い環境では再発したという報告が複数寄せられています。2026年3月の投稿では、ロックの再試行回数が5回・待機時間の上限が7.5秒程度に設定されているため、10並行を超えるような高負荷では待ちきれずに失敗すると分析されていました。2026年4月の別の報告でも、v2.1.97でロック機構を確認したうえで「3並行を超えたあたりから再試行の余地が足りない」との指摘があります。

エディタからバックグラウンドで多数のclaude -pプロセスを起動するような使い方は、この競合が起きやすい典型例です。通常の対話利用で2〜3セッションを並行して開く程度であれば、v2.1.81以降の修正でほとんどのケースが解消されている一方、CI的にプロセスを大量並列起動する用途では、バージョンを最新にしても再発する余地が残っている点は覚えておく価値があります。

今すぐ試せる対処法

まず現在の認証状態を確認します。

/status

Loginの行にExpiredのような表示が出ていれば、/loginで再認証します。

/login

その上で、以下を順に確認します。

• Claude Codeを最新版に更新する。OAuthリフレッシュの競合対策はv2.1.81からv2.1.248まで複数バージョンに分かれて入っているため、古いバージョンのままだと解消済みのはずの不具合を踏み続けることになります。

claude update

• 並行して開いているセッション数を確認する。ターミナルタブやVS Codeウィンドウを多数同時に開いている場合、一時的に減らして症状が止まるか確認します。
• システムクロックが正しいか確認する。公式ドキュメントは、頻発する場合はシステム時刻の正確さを確認するよう案内しています。トークンの検証は正しいタイムスタンプに依存します。
• SSH経由でmacOSを使っている場合はKeychainの状態を確認する。SSHセッション中はKeychainがロックされて書き込みを拒否することがあり、その場合は認証情報が平文の~/.claude/.credentials.jsonへフォールバックして保存されます。
• CIやバッチ処理で多数のプロセスを並列起動する場合はCLAUDE_CODE_OAUTH_TOKENを検討する。claude setup-tokenで発行するトークンは各プロセスが個別に保持でき、/loginの共有クレデンシャルを複数プロセスで奪い合う構図を避けられます。ただしRemote Controlの確立やclaude.aiコネクタの取得はできない制限があるので、用途に合うか事前に確認します。3方式の使い分けはClaude Codeログイン方法3種の使い分けにまとめています。

claude setup-token

表示されたメッセージが特定の文言に該当する場合は、それぞれ専用の記事で対処を扱っています。OAuth token revokedやOAuth token has expiredが出ている場合は「OAuth token revoked」の対処、claude.aiコネクタ利用中にrejected the session tokenが出ている場合は「rejected the session token」エラーの対処を確認してください。ANTHROPIC_PROFILE経由で認証していてAnthropic profile login expiredが出る場合は/loginでは直らないことがあり、「Anthropic profile login expired」の対処法で見分け方を扱っています。/loginのたびに認可画面とサインイン画面を行き来して完了しない場合は、今回説明した競合とは別の不具合で、Claude Codeでログインがループする問題にまとまっています。

まとめ

Claude Codeで何度も再ログインを求められる場合、最も多い原因は複数セッションが同じ認証情報を共有し、OAuthリフレッシュトークンの更新タイミングが衝突することです。公式changelogではv2.1.81からv2.1.248にかけて段階的に対策が入っており、通常の並行利用ならバージョンを最新にするだけで大きく改善します。CIや自動化で多数のプロセスを並列起動する用途では、v2.1.97以降でも高負荷時の再発報告が残っているため、CLAUDE_CODE_OAUTH_TOKENによるプロセスごとの認証分離も選択肢に入れておくと安定します。