Claude Desktopでキーチェーンの許可を毎回求められる原因と対処

Macのキーチェーンまわりでは、症状が2通りに分かれます。「Claude Code-credentials」へのアクセスを許可するダイアログが数分おきに出続ける症状と、全セッションが同時にログアウトして認証情報が空になる症状です。舞台は同じ項目ですが、原因は別々に報告されています。

「Claudeにパスキーの列挙を許可しますか」というダイアログは、キーチェーンの「Claude Code-credentials」の許可とは別の話です。詳しくは後半の節にあります。

症状の見分け方を先に置き、そのあとで原因ごとの報告内容と、ドキュメントにある復旧手順を扱います。

くらべる

症状で見分ける2つの原因

項目へのアクセス権の問題

許可ダイアログが出続ける

OSがキーチェーンのパスワードを求める画面が繰り返し出ます。「常に許可」を押しても止まりません。

トークンの書き換えの問題

全セッションがログアウトする

Failed to authenticate: OAuth session expired and could not be refreshedが出て、開いていた全セッションが同時にログインを求めます。

許可ダイアログが数分おきに出る原因

この症状を詳しく調べた報告が、GitHub Issue #77697です。報告者の環境はClaude Code 2.1.207のCLIで、tmuxもSSHも使わず、ターミナルのセッションを1つだけ開いた状態でした。Desktopの並行セッションとは無関係に起きた報告です。

報告者の調べでは、Claude Codeは認証情報をキーチェーンの項目「Claude Code-credentials」に保存し、読み出しのたびに/usr/bin/securityを呼び出しています。この項目が、信頼済みアプリケーションのリスト(trusted-application list)を持たない状態で作られていました。macOSは信頼済みリストが空の項目を読むたびにパスワードを求めます。LLMを呼ぶたびに読み出しが走るので、実質3〜4分に1回のペースでダイアログが出ます。

「常に許可」が効かない理由も、同じ報告に載っています。報告者によれば、Claude Codeが項目を書き換えるたびに信頼済みリストが失われ、いま許可したアクセス権も消えます。

報告者はこの仮説を、次の手順で検証しました。

• 信頼済みアプリを-Tで指定して作ったテスト用の項目は、2回読んでもダイアログが出なかった(キーチェーン自体は正常)
• Claude Codeの項目を-T /usr/bin/security付きで作り直すと、ダイアログは約3〜4分に1回から約1時間45分に1回に減った
• 残った1回は、Claude Codeが項目を書き換えた時刻(15:55)とぴったり重なった

つまり、手動で-Tを付けても書き換えのたびに元に戻ります。頻度は下がっても、ゼロにはなりません。

ここでもう1点、ドキュメントとの食い違いがあります。ドキュメントによれば、macOSでキーチェーンが書き込みを拒否したとき、Claude Codeは~/.claude/.credentials.jsonに保存を切り替えます。一方で報告者は、有効な.credentials.jsonを置いたうえでキーチェーンの項目を消しても、Claude Code自身が項目を作り直し、ダイアログが再開したと書いています。ファイルがキーチェーンより優先して読まれるわけではないので、ファイルを置いてダイアログを避ける、という使い方は成り立ちません。

Issueのコメント欄では、この症状が長引いている様子も読み取れます。2.1.217で「少しましになったが残っている」、2.1.233や2.1.246(macOS 26.5.2)でも再現した、という書き込みが続いています。

ダイアログの原因は信頼済みリストだけではない

同じ「許可ダイアログが止まらない」でも、コメント欄には別の原因を指す報告が並んでいます。症状が同じなので、手を動かす前にどれに当たるかを見分けておくと遠回りになりません。

原因

ダイアログが止まらないときの3つの原因候補

• 信頼済みリストが空

  Issue #77697の本題です。Claude Codeが項目を書き換えるたびにアクセス権が失われます。報告者の環境は、CLIをターミナル1つで使う構成でした。

• 他のアプリが項目を書き換える

  Nextcloudのデスクトップクライアントを入れている環境で、同じ項目を起動のたびに書き換えているという報告があります。Claude Codeが動く前から項目が変わっているのが目印です。

• 同名の項目が2件ある

  security dump-keychain | grep -c "svce.*Claude Code-credentials"が2を返す環境があります。片方だけを直しても、もう片方で再発します。

2つ目のNextcloudの話は、#77697のコメントに2026年10月1日付で載っています。コメントの主は、許可リストにteamid:NKUJUXUJ3Bだけが入っていたことを手がかりに追跡しました。このteam IDはAnthropicではなくNextcloudのもの(NKUJUXUJ3B.com.nextcloud.desktopclient)で、codesign -dv /Applications/Nextcloud.appで確かめられる、という説明です。

Nextcloudは起動のたびに、自分のキーチェーン項目を書き換えた約4秒後に「Claude Code-credentials」にも手を入れていました。項目のアカウント名はmacOSのユーザー名なので、Nextcloud側がアカウント名だけで項目を拾っているように見える、とコメントの主は推測しています。

このteam IDは、以前のコメントで紹介された回避策のコマンド(security set-generic-password-partition-list -S apple-tool:,apple:,teamid:NKUJUXUJ3B ...)にも入っています。コピーして実行すると、他社アプリの識別子を許可リストに足すことになる点に注意が必要です。同じコメントの主は、Nextcloudが入っているなら「これは#77697の重複ではない」と結論づけています。Nextcloudを使っていない環境には当てはまりません。

3つ目の重複項目は、2026年9月1日のコメントが出どころです。Claude Code 2.1.251とVS Code拡張の環境で、security dump-keychainの出力に同名の項目が2件ありました。前述のパーティションリストを直しても片方にしか効かず、ダイアログが続いたという内容です。

この報告者は、両方の項目をsecurity delete-generic-password -s "Claude Code-credentials"で2回消し、/loginをやり直すと直ったと書いています。ただし8月31日と9月2日の2回とも同じ手順が必要で、重複が戻ってきたとも述べています。複数のプロセスが同時に認証情報を書く経路が、重複を作っている可能性を疑っています。

どちらの手順も、開発元が案内するものではなく利用者の報告です。#77697には、security unlock-keychain ~/Library/Keychains/login.keychain-dbを手動で実行したら改善した、というコメントも2件あります。項目を消すと保存済みのログインも消えるので、再ログインが前提になります。

認証情報が空になって全セッションがログアウトされる

もう一つの症状は、キーチェーンの中身が空になり、OAuth session expired and could not be refreshedで全セッションが落ちるケースです。報告はGitHub Issue #88583に集まっています。

投稿者の環境は、Claude Desktop内蔵のエンジン2.1.229を5つ同時に動かしたmacOSで、稼働時間は22時間から1.5日でした。1〜3日おきに全セッションが同時に落ちるため、キーチェーンを20秒おきに監視するスクリプトを置いて、書き換えの瞬間を捕まえています。記録したのはトークンの長さだけで、値は記録していません。

監視ログは、トークンが約8時間おきに正常に更新される様子をまず示します。8月17日夕方から8月20日の未明まで8回連続で更新が成功し、アクセストークンの期限切れ後も、約40秒後と約1時間後には回復していました。

そして8月21日の午前2時37分、スリープ復帰の後と見られるタイミングで、accessTokenとrefreshTokenが空文字、expiresAtが0に書き換えられました。約4週間先の期限が残るrefreshTokenExpiresAtや、プランの種別などの秘密でないフィールドは無傷でした。

投稿者の分析では、原因は2つの挙動の組み合わせです。1つ目は、claude.aiログインのトークン更新にプロセス間の調整がないことです。MCPサーバー接続のトークンは、v2.1.136で単一のロックを通すよう直されました。claude.aiログインの更新はこのロックを通っていないように見える、と書かれています。

2つ目は、失敗した側が空の状態を書き込んでしまうことです。1回しか使えないリフレッシュトークンを複数のセッションが同時に使うと、遅れた側はinvalid_grantを受けます。遅れた側がその失敗状態を保存し、先に成功した側が書いた新しいトークンを上書きします。スリープから復帰した直後は、全セッションが「期限切れ」を同時に見つけて更新を始めるので、条件がそろいやすくなります。

DesktopだけでなくCLIでも同じ症状が出ている

この症状はDesktop固有ではありません。Issueの後続コメントには、CLIだけの環境で同じ症状が出た報告が並んでいます。

• 複数のgit worktreeのペインでCLIを並べるツールを使った環境で、1つのセッションが動いている最中にも/loginを何度も求められた
• 2.1.257(macOS・ネイティブCLI)で、CLAUDE_CONFIG_DIRの違う2つの項目が2秒差で書き換えられ、どちらも空になった。claude auth statusはloggedIn: falseを返した
• 2.1.276(macOS 26・ネイティブCLI)で、tmux上の10個のclaude remote-controlサーバーが1つの項目を共有していた。全サーバーが同じ秒に「Reconnected」を出した約2分後、項目が空になった

3つ目の報告には、気づきにくい点がもう1つあります。サーバーは各自のメモリにトークンを持っているので、項目が空になったあとも「Ready」の表示のままでした。ところがスマホから起動した子セッションは、すべて認証に失敗していました。表示は正常でも、実際には使えない状態があり得ます。復旧には対話的な/loginと、10台すべてのサーバーの再起動が必要だったと書かれています。

別の報告では、並行セッションの認証失敗と同時刻に、オートモードの安全判定がtemporarily unavailableを返した例があります。判定のためのモデル呼び出しも同じ認証情報を使うなら、トークンが空になったことが「モデルが一時的に使えない」という別のエラーに見えるかもしれません。エラー文言だけで原因を決めつけず、claude auth statusでloggedInの状態を見るほうが切り分けやすくなります。

ドキュメントの記述と、その後の報告

トラブルシューティングドキュメントには、1台のマシン上の並行セッションは保存済みのログインを共有し、トークンの更新は1プロセスずつ順番に処理される、とあります。v2.1.211より前は、スリープから復帰したときに2つのセッションが同じトークンで同時に更新して、保存済みのログインが失効し、開いていた全セッションが再ログインを求められることがあった、という記載もあります。

それでもIssue #88583には、v2.1.211より後のDesktop内蔵エンジン2.1.229や、CLIの2.1.257・2.1.276での再現が載っています。同じ項目を複数のプロセスが共有する構成では、調整が働かない経路がまだ残っているように見えます。

なお、ある報告者はDesktop内蔵のエンジンが、トークンをアプリからCLAUDE_CODE_OAUTH_TOKENで受け取っていると観察しています。Desktopのエンジンがキーチェーンを直接書き換えるのかどうかは、報告のあいだで観察が分かれています。

設定ディレクトリを分けると項目も分かれる

ドキュメントによれば、CLAUDE_CONFIG_DIRを設定すると、.credentials.jsonもキーチェーンの項目もそのディレクトリごとに別になります。複数の設定ディレクトリを使う構成なら、書き換えの競合が起きる範囲を分けられる可能性があります。

あるコメントでは、Claude Code 2.1.247で別々の絶対パスをCLAUDE_CONFIG_DIRとCLAUDE_SECURESTORAGE_CONFIG_DIRに同じ値で設定し、項目名がClaude Code-credentials-<パスのSHA-256の先頭8桁>に分かれることを確かめています。4つの並行プロセスを2つの名前空間で動かしても、401エラーやログインの繰り返しは起きなかったそうです。コメントの主は、これを原因の解消ではなく、緩和と診断のための方法と位置づけています。

復旧手順は症状ごとに入口が違う

ドキュメントにある復旧フローは、キーチェーンが書き込めなくなったときの手順です。ダイアログの原因が上の3つのどれかで、キーチェーンの書き込み自体は通っているなら、ここに入る必要がない場合もあります。

手順

キーチェーンを書き込み可能に戻す手順(ドキュメントの復旧フロー)

1. 1

   キーチェーンの状態を診断する

   ターミナルでclaude doctorを実行します。書き込めないときは、macOS Keychain is not writableで始まる警告と対処案が並びます。警告が出なければキーチェーンは書き込み可能なので、最後の手順へ進みます。

   bash

   claude doctor

2. 2

   ロックされたキーチェーンを解除する

   パスワードを求められたら、キーチェーンのパスワードを入力します。解除できていれば、もう一度claude doctorを実行したとき警告が消えます。

   bash

   security unlock-keychain ~/Library/Keychains/login.keychain-db

3. 3

   警告が残るならパスワードを同期する

   「キーチェーンアクセス」でloginキーチェーンを選び、「編集」→「キーチェーン"login"のパスワードを変更」を開きます。アカウントのパスワードとそろえたあと、もう一度claude doctorを実行します。

4. 4

   ログアウトとログインをやり直す

   キーチェーンが書き込める状態に戻れば、Claude Codeは次に認証情報を書くときに保存先をキーチェーンへ戻します。すぐ反映したいときは/logoutのあと/loginを実行します。

claude doctorは、現在のディレクトリの設定ファイルを信頼確認なしで読みます。v2.1.287のclaude doctor --helpには、この点と、修復まで含む点検はセッション内の/doctorで行うことが書かれています。

/logoutは保存済みの認証情報を全部消します。平文の.credentials.jsonの中身、保存済みのMCPサーバーのログイン、プラグインの機密値が対象なので、MCPの再認可とプラグインの秘密値の再入力が必要です。また、Console経由のログインでAPIキーを作る操作は、キーチェーンが書き込めるようになるまで失敗します。

security unlock-keychainはmacOSの標準コマンドなので、CLIが入っていない環境でも実行できます。パスワードの同期の手順も、「キーチェーンアクセス」だけで進められます。

利用形態ごとに報告されている症状

報告された範囲で、利用形態と症状を並べると次のようになります。

SSHの行は不具合ではありません。キーチェーンがSSHセッションでロックされているなどの理由で書き込みが拒否されると、Claude Codeは~/.claude/.credentials.json(ファイルモード0600)に保存を切り替えます。

ほかに混同しやすい点

• v2.1.281の修正は別の症状を対象にしています: v2.1.281(2026年9月23日)の変更履歴には、ログインキーチェーンがロックされているとき(スリープ復帰直後など)に、保存済みのMCP OAuthトークンが失われたり、キーチェーンの項目が削除されたりする問題の修正があります。claude.aiログインのトークンが空になる問題や、ダイアログが止まらない問題とは対象が別です。
• インストール経路の入れ替えで直ったという報告: #77697には、~/.local/share/claudeにあるスタンドアロンのバイナリと壊れた項目を消し、Homebrewのclaude-codeを入れ直して/loginしたら直った、というコメントがあります。別のコメントでは、node経由のインストールが問題だったとして、Homebrew版を使うことで収まったと書かれています。いずれも開発元が案内する手順ではありません。入れ替えの手順はClaude Code Macインストールで比較しています。
• トークン失効はDesktop以外でも起きます: バックグラウンドで動くエージェントのトークン失効は、Claude Code全体の論点です。過去の修正例はClaude Code v2.1.203で扱っています。

「パスキーの列挙を許可しますか」と出たとき

「Claudeにパスキーの列挙を許可しますか」は、パスキー(WebAuthn)の利用許可を求める表示です。キーチェーンの「Claude Code-credentials」のパスワード要求とは対象が違います。

文言から見て、Desktopのブラウザペインやビルトインブラウザでパスキーを求めるサイトを開いたときに出る表示と考えられます。Desktopのブラウザペインやビルトインブラウザでは、パスキーそのものが使えないという報告がGitHub Issueに上がっています(どちらもこのダイアログの文言には触れていません)。

• #77473(2026年7月、Claude Code 2.1.142・macOS): ビルトインブラウザがパスキー認証に対応せず、GitHubへのログインができなかった
• #101194(2026年10月、Desktop 2.31226.1・macOS 27.0.1): Browserペインでパスワードアプリのオートフィルとパスキーが使えない

どちらも開いたままの不具合報告で、このダイアログが出る正確な条件や、許可した場合の挙動は書かれていません。パスキーが必要なサイトのログインは、通常のブラウザで済ませるのが確実です。

まとめ

ダイアログが続くなら、項目を書き換えているのがClaude Codeなのか、他のアプリなのか、重複した項目があるのかを先に切り分けると、無駄な作業を減らせます。全セッションがログアウトされるなら、同じ項目を共有しているプロセスの数が手がかりです。

Desktop本体のインストールや初期設定でつまずく場合は、Claude Desktop Mac版のインストールと初期設定を併せて見てください。標準のCLIで使う前提はClaude Codeの全体像にあります。