Claude Desktopのサインインで「We couldn't verify your browser」と出るとき
Claude Desktopのサインインが「We couldn't verify your browser」で止まる件の症状、報告された環境、通った例と通らなかった例、手元で試す順番をまとめます。
Claude Desktopのサインイン画面に「We couldn't verify your browser. Try again, or contact support if it keeps happening.」と赤く出て先へ進めない場合、アプリや端末を壊したわけではない可能性が高いです。GitHubでは2026年10月20日以降、同じ文言の報告が重なっています。同じ端末のブラウザーでは入れるのに、アプリだけが通らないのが特徴です。原因は報告時点で特定されておらず、Anthropic側の対応もissue上には出ていません。ここでは、報告された事実と、手元で安全に試せる切り分けの順番をまとめます。
どんな症状が報告されているか
最初に詳細な再現手順を出したのは、macOSでClaude Desktopを使っていた報告者です。数か月サインインできていたアカウントで、2026年10月18日に前のセッションが session_stale_relogin という理由で拒否され、サインイン画面に戻されました。そこから先が通りません。
報告者が踏んだ手順と結果
- 1
Googleで続ける
「Continue with Google」を押し、システムのブラウザーでGoogleの認証を済ませてアプリに戻ります。赤い枠に「We couldn't verify your browser」と出ます。ログには
POST /api/auth/verify_googleが400でinvalid_request_errorを返した記録が残りました。 - 2
メールで続ける
アカウントのメールアドレスを入れて「Continue with email」を押します。ブラウザーは使いません。それでも「Couldn't verify your browser. Try again.」と出て、ログには
POST /api/auth/send_magic_linkの400が残りました。 - 3
同じ端末のSafariで試す
同じMac、同じネットワークでSafariからclaude.aiにサインインすると、問題なく入れました。
注目点は、メール経路ではブラウザーを一度も開いていないのに「ブラウザーを確認できない」と出ていることです。文言は「いま使っているブラウザーが怪しい」と読めますが、実際にはサインイン要求そのものが検証で弾かれているように見えます。何が拒否の根拠なのかは、画面にもログにも出ていません。報告者自身も、400の本文(拒否理由)をアプリがログに残さないことを問題にしています。
効かなかった操作と、通った操作
報告者は、よく試される対処をほぼ一巡させています。どれも結果は同じでした。
| 試した操作 | 結果 |
|---|---|
| Cookieの削除 | 結果変化なし |
プロファイル全体(~/Library/Application Support/Claude)を退避して作り直す | 結果変化なし |
| 公証済みDMGからのクリーン再インストール | 結果変化なし |
| アプリをVPNの対象から外す(tcpdumpで確認) | 結果変化なし |
| VPN内でIPv4に固定する | 結果変化なし |
| 時計・DNS・プロキシ・hosts・拡張機能の点検 | 結果異常なし、結果は変化なし |
| VPNの出口を別の国のリレーに変える | 結果メール経路だけ通った |
最後の行だけが結果を動かしました。同じリレーでGoogle経路をもう一度試すと、verify_google は引き続き400を返しています。つまり出口IPを変えたときに通ったのは、メールで入る経路だけです。
アプリのバージョンは2.42304.2(新規ダウンロードのDMG)と3.1623.0(自動更新後)の両方で同じ結果でした。報告者は、2.42304.2が10月18日までは動いていた点を挙げ、アプリ側の変更ではなくサーバー側の変化だと推測しています。これは報告者の見立てで、検証された結論ではありません。
影響範囲はMacのDesktopだけではない
issueには、その後6件のコメントが付いています。内容を並べると、症状の広がりが見えます。
- Windows(オーストラリア)で同じ症状が出ているという報告
- 米国のWindows 11で同様という報告
- Macで、使うブラウザーを変えても同じという報告
- スペインの研究機関のネットワークからClaude Codeにログインしようとして発生した報告。別のブラウザーでも、同じPCの別アカウントでも再現し、VPNで別の機関のネットワークへ切り替えると直ったとあります
- 内容を書かずに同じ症状を伝える短いコメントが1件
スペインの報告は、出口IPが原因になっている可能性を裏づけます。研究機関のように多数の人が同じ出口IPを共有する環境では、特定のIPがまとめて検証に引っかかる、という想像が成り立ちます。ただしAnthropicが検証の基準を明らかにしているわけではなく、IPが原因だと確定した情報はありません。「出口を変えると通る例がある」という事実にとどめて読むのが安全です。
Windowsとスペインの報告は、Desktopに限らずClaude Codeのログインでも出ています。ブラウザーで認可画面を開く点が共通で、サインイン検証を担う部分が共通している可能性があります。
通常のブラウザーでだけ失敗し、シークレットウィンドウでは通る例
別のissueでは、さらに手がかりの多い報告が出ています。Windows 11のChromeで、VS Code拡張からClaude.aiのサブスクリプションでログインしようとした例です。
通常のChromeプロファイルでは、認可ボタンを押した数秒後にログイン画面へ戻されました。「Sign in again」から入り直すと、Googleで続けた時点で同じ「We couldn't verify your browser」になります。同じマシン、同じネットワークで、認可URLをシークレットウィンドウに貼って開くと、同じGoogleアカウントで認可まで進みました。画面に出た認証コードを拡張機能へ貼ると、ログインが完了しています。
報告者は、Googleの同期が止まっていたことを示す「Verify it's you」のチップが同日に出ていた点も書いています。通常プロファイルのセッションCookieが失われているか、整合していない可能性を示唆していますが、DevToolsでの検証までは行っていないと断っています。したがってこれも原因ではなく手がかりです。
Desktopアプリはシステムのブラウザーを経由するGoogle経路を持つため、通常のブラウザーのCookieや拡張機能の状態が結果を左右する余地があります。一方で、先のMacの報告はプロファイルを作り直しても再現しており、メール経路は同じ症状でした。2つの報告は原因が違う可能性もあります。
手元で試す順番
どの手も、アカウントの設定やデータを変えるものではありません。上から順に、1つずつ試して結果を見ます。
「verify your browser」の切り分け
- Q同じ端末のSafariやChromeで、claude.aiにサインインできるか?答えがいいえのとき答えがはい
端末側ではなくアカウントやネットワークの問題かもしれません。サポートに連絡する段階です(下の「報告するときに添える情報」を参照)。
- QGoogleとメールのどちらの経路でも同じ表示か?答えがいいえのとき答えがはい
通る経路があるなら、そちらを使います。メールで入れる場合は、マジックリンクの到着が遅いことがあるため、再送を連打せず数分待ちます。
- Q別のネットワークに切り替えると通るか?答えがいいえのとき答えがはい
スマートフォンのテザリングなど、出口IPが変わる経路で試します。通るなら、出口IPが検証に関わっている可能性が高まります。
通らない場合は、記録を残して報告する
ここまでで通らなければ、症状を日付付きで控え、サポートとissueの両方に伝えます。
出口IPを切り替える手段として報告に出ているのはVPNですが、会社や学校のVPNを私的に切り替えるのは規則に触れる場合があります。許可された範囲で、テザリングや自宅回線など別の経路を使うほうが無難です。
Claude Codeのログインで同じ文言が出た場合は、ログイン時にコピーしたURLをシークレットウィンドウで開く方法があります。公式ドキュメントによると、ブラウザーが自動で開かないときは c キーでログインURLをコピーでき、ブラウザーがコールバックに戻れない場合は表示されたコードを端末に貼って完了できます。
claude auth login
# ブラウザーが開かない/通常プロファイルで失敗するとき:
# 表示されるURLを c キーでコピーして、シークレットウィンドウに貼る
# 画面に出た認証コードを "Paste code here if prompted" に貼るログインに成功したかは、claude auth status --text で確かめられます。シークレットウィンドウの報告でも、この出力が「Claude Pro account」になったことで成功を確認しています。
「古いセッションの再ログイン」が引き金かもしれない点
最初の報告者は、期待される動作として、アカウントのセッションが生きているのに、アプリ側の古いセッションの印(session_stale_relogin)だけで完全な再ログインが始まるのは避けてほしいと書いています。つまり、10月18日にセッションが無効になり、そのままサインイン画面へ戻されたことが、一連の失敗の入口でした。
数か月サインインしたままだったアカウントで、突然サインイン画面に戻された場合は、このパターンに当たる可能性があります。ただし、そのあと400が返る理由は、issueの時点で説明されていません。
報告するときに添える情報
公式の案内では、ログインの堂々巡りや契約の認識漏れなど、アカウント側の問題はサポートへ連絡します。claude.aiにサインインした状態で、左下のイニシャルから「Get help」を選ぶ流れです。サインインできない場合の連絡手段は、ヘルプセンターの「How to get support」に流れが載っています。
GitHubのissueへ状況を足すなら、次の情報があると原因の切り分けに使われます。
- OSとClaude Desktopのバージョン、あるいはClaude Codeのバージョン
- どの経路(Google、メール)で、どの表示が出たか
- 同じ端末の通常ブラウザーとシークレットウィンドウの結果
- ネットワークの種類(自宅、会社、大学、VPN)と、出口を変えたときの結果
- 失敗が始まった日付と、その直前に起きたこと(セッション切れなど)
出口IPのアドレスそのものは、公開のissueには貼らないほうが安全です。国や接続の種類を書けば足ります。
似た症状との見分け方
文言が似ていても、原因の違う不具合がいくつかあります。見分けのヒントを表にします。
| 症状 | 当てはまる記事 |
|---|---|
| 認可後にログイン画面へ戻り続け、stateパラメータが落ちる | 当てはまる記事Claude Codeのログインが堂々巡りになる件 |
| 社内プロキシ越しに認証が失敗する | 当てはまる記事Claude Desktopの認証失敗とプロキシ |
| サインイン用のメールが届かない、遅い | 当てはまる記事ログイン用メールが届かないときの対処 |
| サインイン状態が保存されない(Chromebook) | 当てはまる記事ChromebookのDesktopサインイン保存 |
サインイン方法の全体像はClaudeのログイン方法ガイドにまとめています。「We couldn't verify your browser」はこの4つとは別の、検証の段階で出る表示です。
まとめ
この表示は端末の故障を示すものではなく、サインイン要求の検証で400が返っている状態です。出口IPを変えると通る例と、シークレットウィンドウなら通る例があり、条件は環境ごとに違います。原因が特定されるまでは、別のネットワーク、別のブラウザープロファイル、通る側の経路を順に試し、結果を日付付きで残しておくと、サポートやissueへの報告がそのまま役に立ちます。