「another Claude Code process is refreshing it」の意味と対処

このエラーは、ログインが拒否されたという意味ではありません。保存済みのclaude.aiログインが期限切れになり更新が必要になったところで、同じパソコンの別のClaude Codeプロセスが更新用のロックを握っていた、あるいは握ったまま終了して残していったため、このセッションはリクエストを送る前に止めた、というのがClaude Code公式のエラー一覧の説明です。ロックの実体は~/.claude/.oauth_refresh.lockという空のフォルダで、~/.claude.lockという2つ目のフォルダも同時に使われます。

まず1分待って同じコマンドを再実行してください。2026年11月12日にClaude Code 2.1.316で確かめたところ、誰も更新しなくなったロックは最後の更新から60秒で古いとみなされ、次の実行で自動的に回収されました。それでも出るなら、他のClaude Codeのウィンドウやプロセス（VS Code、別ターミナル、Claude in Chrome、スクリプト）を閉じて再実行します。ほかに何も動いていないのに続く場合は/loginでサインインし直します。サインインはこのロックを待たないと公式ドキュメントに書かれています。

例外は、待っても消えないロックです。時計が戻ってロックの時刻が未来になっている場合や、Windowsで空のフォルダが残り続けたという報告では、Claude Codeが1つも動いていないことを確かめてから空の.oauth_refresh.lockフォルダを消すと（macOSとLinuxではrmdir）、すぐ直っています。.credentials.jsonやキーチェーンの項目は消さないでください。消すと本当にログアウトします。

2つの表示と「ロック」の正体：~/.claudeの空フォルダ

同じ原因のエラーが、使い方によって2つの文面で出ます。公式のClaude Codeエラーリファレンスによると、ターミナルで対話的に使っているときは次の文です。

Could not refresh your login because another Claude Code process is refreshing it (or exited mid-refresh) · Try again in a minute; if it keeps happening, close other Claude Code windows or sign in again with /login

claude -pによる非対話モードとAgent SDKでは次の文になり、構造化されたエラーコードはserver_errorです。VS Code拡張やスクリプトから見えるのは、たいていこちらです。

Failed to refresh OAuth token: another Claude Code process is refreshing it or exited mid-refresh. This is usually transient; retry in a minute, and if it persists close other Claude Code processes or sign in again

「ロックファイル」と呼ばれがちですが、実体はファイル1つではありません。当サイトのMac 1台で2026年11月12日、Claude Code 2.1.316がログインを更新している最中に設定フォルダを見ると、置かれていたのは次の3つでした。本物のログインは使わず、CLAUDE_CONFIG_DIRで隔離した設定フォルダに偽の認証情報を置いて実行しています。

プロセスが正常に終わると、3つとも消えていました。CLAUDE_CONFIG_DIRを設定している場合は、すべてそのフォルダ基準に移ります。たとえば設定フォルダが/work/ccなら/work/cc/.oauth_refresh.lockと/work/cc.lockです。owner ファイルのpidSpaceにはパソコンのホスト名がそのまま入るので、issueなどに貼るときは伏せてください。

なぜ「1分後に再試行」なのか：約8秒で失敗し、60秒でロックが回収される

「1分」には根拠があります。2.1.316のコードを読むと、ロックを握っているプロセスは5秒ごとにフォルダの更新時刻を新しくし、更新時刻が60秒より古いロックは「古い」とみなされて次のプロセスに取り除かれます。待つ側は1〜2秒のランダムな間隔で5回取り直しを試み、そのあと7.5秒の間にロックの時刻が動いたかを見ます。動いていなければ保持者は生きていないと判断します。

2026年11月12日に同じ条件（Claude Code 2.1.316、Mac 1台、隔離した設定フォルダの偽の認証情報）でclaude -pを実行したところ、作ったばかりで誰も触らない空のロックフォルダを置いた場合は約8秒（7.9秒、8.0秒、8.6秒）で-pの文が出て終了コード1になり、すぐ再実行しても同じでした。ところが同じロックのまま作成から65秒後に再実行すると、ロックは自動で回収されて通常の更新処理に進み、更新時刻が5分前のロックは最初の実行で即座に回収されました。旧式の<設定フォルダ>.lockだけを置いた場合も、約7.9秒で同じ文が出ました。

逆に、2秒ごとに時刻を更新し続けるロック（生きている保持者の再現）では、この文は出ませんでした。Claude Codeは35秒ほど待ったあと、古いトークンのままリクエストを送っています。つまりこの文が出た時点で、ロックは少なくとも数秒間まったく動いていなかったことになり、1分待てば放置されたロックが60秒の期限を過ぎて片付けられるので、次の実行が通ります。例外は時刻が未来のロックで、30日先の時刻にしたロックは65秒後も残り、同じ文が出続けました。このときはrmdirでフォルダを消すと、すぐ通常どおりに戻りました。

この確認は偽のトークンで行ったため、ロックの扱いだけを見ています。Windows、本物のログイン同士の競合、旧式ロックが60秒後に消えるかどうかは試していません。なお2.1.282の変更履歴には、更新中に閉じられたプロセスのあと最大1分このエラーで失敗する問題を修正したとあり、2.1.316のコードにも、owner ファイルから保持者のプロセスがすでに終了していると判断できれば60秒を待たずに引き継ぐ処理があります。ただしAnthropic側の機能フラグで有効になっている場合だけ動くため、手元では早く回収される場合がある、という程度に考えてください。

どのケースか見分ける：直前にしていたことと見える症状

多くの場合、エラーの直前に何をしていたかで原因の見当がつきます。下の表の原因欄で「報告」とあるものは、GitHubに寄せられた利用者の報告です。修正バージョンはClaude Codeの変更履歴によります。

何も変えずにロックの持ち主を確かめる手順

ロックを消す前に、今それを握っているプロセスが本当にいないかを確かめます。次の手順はどれもファイルやプロセスを変更しません。ファイル名と中身は、前述の当サイトの確認（2026年11月12日、2.1.316）で見たものに基づいています。

1. 他のClaude Codeが動いていないか見ます。macOSとLinuxではps -ax -o pid,lstart,command | grep -i "[c]laude"で一覧できます。ターミナルのセッションのほか、VS Code拡張、--chrome-native-host、--bgで起動したバックグラウンドセッションも対象です。Claudeのデスクトップアプリなど名前にclaudeを含む別のアプリも表示されるので、コマンド列で見分けてください。
2. ロックが残っているかを見ます。ls -la ~/.claude | grep oauth_refreshとls -ld ~/.claude.lockで、.oauth_refresh.lockフォルダ、.oauth_refresh.lock.ownerファイル、~/.claude.lockフォルダの有無が分かります。WindowsではGet-ChildItem "$HOME\.claude" -Force -Filter ".oauth_refresh.lock*"です。何もなければ、ロックはもう解けているので再実行すれば通ります。
3. owner ファイルがあればcat ~/.claude/.oauth_refresh.lock.ownerで中身を見て、pidとprocStart（開始時刻）を手順1の一覧と照らし合わせます。同じPIDと開始時刻のプロセスがいれば、それが保持者です。PIDがいない、または開始時刻が違えば、保持者はすでに終了しています。
4. ロックの時刻を見ます。macOSではstat -f "%Sm %N" ~/.claude/.oauth_refresh.lock ~/.claude.lock、Linuxではstat -c "%y %n" ~/.claude/.oauth_refresh.lock ~/.claude.lockです。10秒ほど空けて2回実行し、時刻が進んでいれば保持者は生きています（5秒ごとに更新されるため）。1分以上前で止まっていれば放置されたロック、現在より先の時刻なら時計が戻ったケースです。

解消の手順：待つ、閉じる、空のフォルダを消す、/login

上から順に試し、直った段階で止めてください。1、2、4は公式エラーリファレンスの案内、3はGitHubの報告者が実際に行い、当サイトの確認でも効いた操作です。

1. 1分待って同じコマンドを再実行します。別のプロセスが先に更新を終えていれば、このセッションは更新済みのログインをそのまま使います。放置されたロックも60秒を過ぎれば回収されます。
2. まだ出るなら、前の手順で見つけた他のClaude Codeのウィンドウとプロセスを閉じてから再実行します。VS Codeは拡張が裏でプロセスを持っているので、ウィンドウごと閉じます。
3. Claude Codeが1つも動いておらず、ロックの時刻が止まったまま（または未来）なら、空のロックフォルダを消します。macOSとLinuxではrmdir ~/.claude/.oauth_refresh.lock、WindowsではRemove-Item "$HOME\.claude\.oauth_refresh.lock"です（#95236、#95739）。報告者はどちらも、消した直後のclaude -pが同じ保存済みログインのまま通ったと書いており、当サイトの確認でもrmdirの直後に通常の更新処理へ進みました。
4. 他に何も動いていないのに続く場合は、Claude Codeで/loginを実行してサインインし直します。

rmdirは空のフォルダしか消せないので、間違えて中身のあるフォルダを指定しても削除されません。~/.claude.lockだけが残っている場合、報告されている解消方法は約1分待って再送することです（#102785）。待っても続くなら手順4に進んでください。

やってはいけないのは2つです。1つは.credentials.jsonやmacOSキーチェーンのClaude Code-credentialsを消すことで、このエラーはログインの拒否ではないため、消すと保存済みログインを自分で捨てることになります。もう1つはpkill -f claudeのような一括終了で、コマンドラインにclaudeを含む別のアプリ（Claudeのデスクトップアプリなど）まで止めてしまいます。閉じるのは手順1で特定したプロセスだけにしてください。

Claude Codeで修正されたバージョンと、2.1.322時点で直っていない問題

AnthropicのClaude Code CHANGELOGには、このロックに関わる修正が次のように記録されています。日付はGitHubのリリース日です。

一方で、2.1.322までの変更履歴には、Windowsでロック作成がEPERMで失敗する問題、時刻が未来になったロック、--chrome-native-host、VS Codeの設定読み込み用プロセスが残す~/.claude.lock、.oauth_refresh.lock.owner.tmp.*という一時ファイルが溜まる問題、ゲートウェイや監視ツールが短いコマンドをタイムアウトで強制終了したあとに空のロックが残る問題（#105729のコメントで8回中8回と報告）のいずれについても記載がありません。強制終了されたプロセスのあと最大1分失敗する問題そのものは、上の表の2.1.282で修正済みとされています。これらはGitHubで報告が続いている段階です。2026年11月12日時点で、Anthropicのスタッフが応じたのは#79688への「本物のバグに見える」という1件だけで、その issue も後に自動で閉じられています。

なお、スリープからの復帰時に2つのセッションが同じトークンで更新してしまい、全セッションが一斉にログアウトされる問題は、公式のトラブルシューティングページによればv2.1.211より前のものです。

再発を防ぐ：VS Code、スクリプト、サーバーとコンテナ

再発しやすさは使い方で変わります。まずClaude Codeを2.1.318以降に上げてください。短いコマンドが更新の途中で終了する問題は2.1.301で修正され、遅い更新のときにclaude auth statusとclaude pluginが保存前に終わる問題も2.1.317と2.1.318で直っています。そのうえで、更新だけでは防げない原因について、環境ごとに次の点を見直してください。公式の案内以外は利用者の報告です。

• VS Codeを複数のウィンドウで開く人は、毎朝最初の起動で複数のプロセスが同時に更新に向かいます。報告者の回避策は、VS Codeの設定で"window.restoreWindows": "one"にして復元するウィンドウを1つにする（#90688）か、VS Codeを開く前にターミナルでclaude -pを1回実行して先にログインを更新しておく（#102785）ことです。どのアカウントで動いているかはVS Code で Claude Code のアカウントを確認する方法：/status、ログイン、API ルートで確かめられます。
• claude -pを並列で回すスクリプトでは、しばらく使っていなかったあとは1本を先に走らせ、それが応答を返してから残りを始めると競合を避けられたという報告があります（#88583）。
• 監視やSSHのログインバナーでclaude auth status、claude doctor、claude agents --jsonなどの短いコマンドを定期的に呼んでいる場合は、まず2.1.318以降に上げてください。2.1.301の修正は短いコマンド全般が対象で、auth statusとplugin listは例として挙がっているだけです。2.1.301のあとも、claude plugin validate（2.1.302／2.1.303、#102265）やauth status（2.1.311、#105645）が遅い更新の保存前に終わる報告が出て、2.1.317と2.1.318の修正につながりました。Windowsでclaude auth statusとclaude agents --jsonを定期実行していた環境でも、2.1.296〜2.1.303でログインが2回失われた報告があります（#103325、この文そのものではなく更新の競合）。2026年11月12日時点で、2.1.318以降に短いコマンドで起きたという報告は見つかっていません。一方、ゲートウェイのclaude auth status --jsonによる確認をタイムアウトで強制終了すると空のロックが残ったという報告（#105729のコメント）に対応する修正は、変更履歴にありません。2.1.301より前の報告者は、auth statusやdoctorの代わりにclaude -p /usageで更新させていました（#95822）。--bgで起動したバックグラウンドセッションの確認と停止は、Claude Code Agent Viewの使い方：claude agentsで起動・返信・復旧するを参照してください。
• サーバーやCIなど対話的にサインインできない自動実行には、公式ドキュメントがANTHROPIC_API_KEYか、claude setup-tokenで作る長期トークンを案内しています。これらは、このロックを使う保存済みログインの更新処理とは別の仕組みで認証します。
• コンテナやVMで起動後に時計が大きく戻る環境では、更新中に時計が戻ると未来の時刻のロックが残ることがあります（#95739）。公式のトラブルシューティングも、ログインを頻繁に求められるならシステムの時計を確認するよう書いています。
• Windowsで多数のセッションを同時に動かす場合、報告者は個別のプロセスを並べる代わりに、claude remote-controlのサーバー1つを--capacity Nで動かしてEPERMを避けていました（#91708）。

Windowsでは60秒を過ぎてもロックが消えないことがある

2026年11月12日のmacOSでの確認（2.1.316）では、放置されたロックは60秒後に自動で回収されました。ところがWindows 11（2.1.272）の報告では、ヘッドレスのclaude -pを連続実行したあと空の.oauth_refresh.lockが残り、180秒待っても同じエラーが続きました（#95236）。報告者がRemove-Item "$HOME\.claude\.oauth_refresh.lock"で消すと、次のclaude -pは3.3秒で成功しています。同じ症状はLinuxのDockerサンドボックスでも報告されており、なぜ回収されなかったのかは分かっていません。

Windowsでは、保存済みログインは%USERPROFILE%\.claude\.credentials.jsonに、ロックは%USERPROFILE%\.claude\.oauth_refresh.lockに置かれると報告されています。多数のプロセスが同時に動くとロックフォルダの作成がEPERMで失敗し、その後OAuth refresh token is no longer validとなって毎朝ログインし直す、という報告もあります（#91708）。また.oauth_refresh.lock.owner.tmp.で始まる一時ファイルが1日に約65個ずつ溜まり811個になった例がありますが、報告者は動作上の問題はまだないとしています（#108764）。

.credentials.jsonやキーチェーンを消す、再インストールは必要か

必要ありません。公式エラーリファレンスは、このエラーはログインが拒否されたのではなく、期限切れのログインを更新しようとしてロック待ちで止まったものだと説明しています。更新に使う保存済みの認証情報はそのまま使えるので、.credentials.json（WindowsとLinux）やキーチェーンのClaude Code-credentials（macOS）を消すと、直るどころか本当にログアウトし、このパソコンのClaude Codeはサインインし直しになります。ロックの報告でも、空のフォルダを消しただけで同じ認証情報のまま通っています。

再インストールも、ロックフォルダは設定フォルダ側に残るので効果がありません。サインインし直したいなら/loginで足ります。

似ているが別のエラー：OAuth session expired、compaction、ディスク容量

Failed to authenticate: OAuth session expired and could not be refreshedやLogin expiredと表示される場合は、保存済みログインの更新自体が失敗したケースで、対処が違います。Claude「Unable to authenticate」対処：待つか再ログインかを見てください。

Error during compaction:のあとに同じ文が続く場合は、会話の圧縮中にこのロックで止まったものです。圧縮側の扱いはClaude Code の compact エラー：メッセージ別の原因と復旧手順にあります。

Failed to refresh OAuth token: the disk that holds the Claude Code config directory ... is fullは、設定フォルダのあるディスクが満杯で新しいログインを保存できない状態です。公式ドキュメントのとおり、サインインし直しても直らないので、不要なファイルを消して空き容量を作ってから再実行します。

Claude in Chromeとの接続（native host）の設定はClaude CodeでClaude in Chromeを使う方法：Edge対応は条件付きを、VS Codeでそれ以外の理由で動かない場合はClaude Code が VS Code で動かない時は、まず失敗している面を分けるを参照してください。