Claude Desktop Linux版で再ログインを繰り返し求められる原因と対処法

Linux版のClaude Desktopで再ログインを求められたら、まず「起動のたびか、約1日おきか」で原因を分けます。起動のたびに求められるなら、サインイン情報をデスクトップのキーリングに保存できていない可能性が高く、設定で直せます。約1日おきなら、サーバー側がセッションを「昇格権限には古すぎる」と判定して無効にする不具合の報告と一致します。こちらは利用者側の設定では止められず、1.49で解消したという報告が1件あります。

起動のたびか、約1日おきかで原因が分かれる

再ログインの出方は大きく2通りに分かれます。どちらに当たるかで、見るべき場所がまったく変わります。

Coworkでローカルフォルダーへのアクセスを許可するときに、数分のうちに2回サインインを求められる症状もあります。これは後半で扱う別のログ行に対応します。

起動のたびに再ログインになるときは、キーリングを見直す

Linux版のサインイン情報は、GNOME KeyringやKDE Walletといったデスクトップのキーリングに保存されます。ロックされたままのキーリングしか無いと保存できず、起動のたびにサインインし直すことになります。公式のトラブルシューティングでは、状況を3つに分けています。

約1日おきの再ログインを報告した人たちは、この原因を先に潰しています。Ubuntuではgnome-keyring-daemonが動作中で、KDEの環境でもkwalletdが「has-wallet」を返し、起動のたびに保存済みのトークンが読み込まれていました。Linux Mintでは、永続的なloginキーリングにChromium Safe Storageが入っていることもsecret-toolとseahorseで確かめられています。キーリングが正常でも再ログインが続くなら、次の節の原因です。

約1日おきに強制サインアウトされるときの挙動

GitHub Issue #89812は、2026年8月26日にUbuntu上のclaude-desktopパッケージ(1.32352.1と1.34493.1)で報告されました。アプリを24時間以上起動したままにすると、session_stale_reloginという理由でセッションが無効になり、claude.aiのログイン画面へリダイレクトされます。同じマシンのブラウザーでclaude.aiにサインインしたセッションは何週間も切れず、影響を受けるのはデスクトップアプリだけです。

Windows 11のログには、サーバーから返ったエラー本文がそのまま残っていました。

Session is not fresh enough to grant elevated access. Sign in again to continue.

同じログには、失効の範囲を絞り込む一行もあります。

sessionKey is valid but too old for the requested scope expansion

セッション自体はまだ有効で、拒否されているのはより高い権限(elevated access)への昇格要求だけです。ブラウザーの通常のチャットはこの昇格要求を出さないため、何週間も切れません。デスクトップアプリは昇格要求を出し、拒否されると、その要求だけを再認証せずにセッション全体をサインアウトします。この解釈はIssue上の利用者による推測です。

放置明けの最初のプロンプトで失敗する例

Linux Mint 22.3(claude-desktop 1.37937.3)の報告では、アプリを起動し続ける必要すらありませんでした。マシンをサスペンドして約8時間放置し、翌朝に起動すると、会話やプロジェクトの閲覧は普通にできます。失敗するのは最初のプロンプトを送った瞬間で、新しい会話に「ok」と送るだけでも、HaikuでもFableでも起きました。

このときログインの画面に出るのは「Sign in to continue — Your session has expired」です。ところが~/.config/Claude/logs/claude.ai-web.logに残るのは、次の1行でした。

[error] Uncaught (in promise) CcrHttpError: startRemoteCoworkSession: 403

実際に返っているのは403であり、期限切れの資格情報ではありません。報告者は、文言のせいでキーリングやOAuthの調査に回り道したと指摘しています。同じ報告には、開いたままだった会話が1つだけ、アプリの2回の再起動と更新をまたいで使えたという説明のつかない観察も添えられています。

失効の別名としてuntrusted_deviceが出る例

Kubuntu(KDE)では、Googleでサインインしている環境から別の型が報告されました。APIトークンのキャッシュはkwalletdから読めているのに、ほぼ毎日Googleのサインイン画面が開きます。main.logには「AddSessionFile denied (untrusted_device); raised the re-login banner」という行がありました。Linux Mintの報告でも同じuntrusted_deviceが出ており、個人のMaxアカウントでSSOも組織のデバイスポリシーも無いのに出ている点が報告者を戸惑わせています。

毎日出ているのはどのログ行かで、原因を見分ける

Issueの中には、日次の再ログインの目印が食い違う報告があります。Windows 11の追試では、session_stale_reloginが出たのは9日間のログでたった2回(どちらも8月21日)でした。毎日のように出ていたのは別の行です。

claudeURLHandler: login loadURL superseded (teardown race)

この行は9日間に8回あり、連続する5つの間隔は21〜26時間の範囲に収まっていました。失効はその瞬間ではなく、失効後の最初の利用で表面化するため、発生時刻は7時台から17時台までばらつきます。報告者は、キーリング読み出しの失敗(using cached tokenの読み出し669回に失敗なし)、アプリの再起動、スケジュールしたCoworkタスクのいずれも原因から外しています。

別のIssue #80494に付いたCachyOS(KDE Plasma、1.40609.0)のコメントでは、session_stale_reloginを含む強制サインアウトが2026年8月31日07時20分34秒と9月1日07時15分15秒に記録され、間隔は23時間55分でした。前者はスリープなし、後者はスリープ明けで、報告者はスリープではなく約24時間の周期が原因だと分析しつつ、同じ問題かどうかは分からないとも書いています。

自分の環境では、main.logにどの行が出ているかを見るのが手がかりになります。Linuxでは~/.config/Claude/logs/main.log、Windowsの標準インストーラー版ではC:\Users\<ユーザー名>\AppData\Local\Claude\Logs\main.logに書かれると報告されています。

grep -E "session_stale_relogin|untrusted_device|teardown race" ~/.config/Claude/logs/main.log

• session_stale_reloginが出る: 昇格要求がサーバーに拒否された強制サインアウトです
• untrusted_deviceが出る: デバイスが信頼済みと見なされていない拒否で、DeviceRegistry: device not registeredという行を伴った例があります
• teardown raceだけが出る: Windowsの追試で、日次の強制サインアウトの目印として報告された行です。session_stale_reloginを伴わない例があります

Coworkのフォルダーアクセスで2回サインインを求められる

#89812の元の報告は、Coworkセッションがローカルフォルダーへのアクセスを求めたときに、数分以内に2回サインインを求められる点も挙げています。1回目のサインインを済ませても、2回目の画面が出ます。ログには次の2行が残っていました。

claudeURLHandler: login loadURL superseded (teardown race)
claudeURLHandler: ignoring repeat delivery of login callback

1回目のログイン処理が終わる前に次のログイン画面の読み込みが割り込み、1回目のコールバックが握りつぶされたように見えます。報告者はこれをクライアント側の不具合と見ており、昇格認証は1回のサインインで通るべきだと述べています。

Issueの経過と、1.49での改善報告

9月10日には、1.49にして1週間以上閉じていたアプリを開き直しても再ログインされなかったという報告が付きました。main.logにelevated_authの行が出なくなったとして、session_stale_reloginとuntrusted_deviceの事例が解消したように見えると述べています。ただし投稿者は1人で、他の利用者からの追試はまだ付いていません。Issueは公開から1か月以上たってもopenのままで、コメントは6件すべてが利用者の報告です。

Linux版は自動更新されないため、更新は自分で適用する

修正が入ったバージョンが出ても、Linux版は自動では届きません。Linux版はアプリ自身では更新されず、システムのパッケージ更新(aptやグラフィカルな更新ツール)で届きます(Claude DesktopのLinux版インストールガイドも同じ説明です)。macOSとWindowsは起動時に自動更新されます。

sudo apt update && sudo apt upgrade

注意が要るのは、.debファイルを直接ダウンロードして入れた場合です。/etc/default/claude-desktopにCLAUDE_DESKTOP_ADD_REPO="false"と書いてリポジトリの登録を止めていると、aptは新しいバージョンを届けません。その場合は、公式のダウンロード手順をもう一度実行して入れ直します。GNOME Softwareなどのグラフィカルな更新ツールも、リポジトリが登録されていれば新しいバージョンを拾います。

今すぐできる対処と、効かない操作

• 約1日おきに求められたら、サインインし直します。その場で復旧します
• 起動のたびに求められるなら、前の節のキーリングの手順を試します
• 約1日おきの場合は、apt upgradeで最新ビルドにしてから様子を見ます。自分の環境のログ行とバージョンをIssueに追記すると、原因の絞り込みに役立ちます
• Coworkの二重ログインは、1回目が弾かれても2回目の画面でそのまま完了させれば先へ進めます

ANTHROPIC_API_KEYやapiKeyHelperを設定しても、Claude Desktopには効きません。Desktopはこれらの環境変数を読まず、OAuthで認証します。Claude ConsoleのAPIキーも直接は受け付けないため、APIキーでの認証が必要ならCLIを使います。サインインではなく、再起動でセッションだけが一覧から消える症状なら、ARM64版の保存エラーが別の原因を扱っています。

CLIで頻発する再ログインとは別の不具合

Claude Codeで何度もログインを求められる原因と対処法は、CLI側の別の不具合を扱っています。複数のターミナルセッションが同じOAuthリフレッシュトークンを共有し、更新のタイミングが衝突して再ログインになる現象です。Desktopの症状は、キーリングの保存失敗か、サーバー側の失効判定やログイン処理の競合が疑われるもので、ローカルのトークン競合とは別系統です。どちらも「何度もログインを求められる」ように見えますが、ターミナルのCLIで起きているかDesktopで起きているかで切り分けられます。

まとめ

起動のたびの再ログインはキーリングの設定で直り、約1日おきの再ログインは利用者側の設定では止められず、サインインし直しと最新ビルドへの更新で様子を見ることになります。自分がどちらかは、main.logにどの行が出ているかで判断できます。