Claude CodeでmacOS 26の/loginが成功してもトークンが保存されない
macOS 26で/loginに「Login successful」と出ても認証情報が保存されず、すぐ「Not logged in」に戻る報告があります。切り分けのコマンドと回避策をまとめます。
macOS 26で/loginを済ませ、画面にLogin successfulと出たのに、次のメッセージを送るとNot logged in · Please run /loginが返る。GitHub Issue #70077は、この症状を報告しています。認証情報がKeychainに書かれていない、というのが報告者の見立てです。
このIssueは、ブラウザが自動で開かないことや、claude doctorの警告も合わせて挙げています。ここでは報告の中身と、手元で状況を切り分けるコマンド、使える回避策を順に扱います。
報告された症状は3つ重なっている
Issue #70077は2026年6月22日に立ち、開いたままです。報告者の環境は、macOS 26.4(Apple Silicon)、Claude Code 2.1.185、Terminal.appです。VS Codeの統合ターミナルでも同じでした。
報告された3つの症状
ブラウザが開かない
/loginでブラウザが自動で開かず、URLが表示されます。同じシェルからopen "https://claude.ai"を実行するとブラウザは開きます。成功表示のあとに未ログイン
URLを手で開き、表示された認証コードを貼ると
Login successfulが出ます。直後の/statusはAuth token: noneです。doctorがKeychainを警告
claude doctorがmacOS Keychain is not writableと報告します。Keychainの項目を消しても、ロック解除しても変わりません。
ブラウザが開かないこと自体は、ドキュメントに想定済みの動きとして載っています。ブラウザが自動で開かないときはcキーでURLをコピーして自分で開きます。ブラウザがコールバックに届かないときは、コードをPaste code here if promptedのプロンプトへ貼ります。症状1は、それだけなら故障ではありません。
問題は症状2です。コードを貼って成功と出たあとに認証情報が残らないのは、想定された動きではありません。
報告者が試して効かなかったこと
報告者は、原因を絞るために次の操作をしています。どれも症状を変えませんでした。
security unlock-keychain ~/Library/Keychains/login.keychain-dbでロックを解除する- 既存の
Claude Code-credentialsの項目を削除して/loginをやり直す - 項目を
-A(すべてのアプリを許可)付きで先に作っておく。/login後も中身はダミーのままだった - 別名のサービスで
security add-generic-passwordを実行する。こちらは成功し、CLIからKeychainへ書けることは分かった
実行ファイルに隔離属性(quarantine)は付いておらず、codesign -vは「コードは有効だがアプリではないようだ」と返したそうです。報告者はここから、macOS 26がアプリバンドル外のネイティブバイナリに課す制限が原因ではないか、と推測しています。これは報告者の仮説で、原因として確認された話ではありません。
自分の環境で切り分けるコマンド
次の順に確かめると、Issueと同じ状態かどうかが分かります。
保存されない状態かを調べる手順
- 1
バージョンとOSを控える
claude --versionとsw_versの出力を控えます。報告は2.1.185のものが起点で、後のコメントには2.1.236もあります。 - 2
doctorでKeychainを見る
claude doctorを実行し、macOS Keychain is not writableで始まる警告が出ていないかを見ます。ドキュメントは、警告が出ないならKeychainは書き込み可能とみなしています。 - 3
項目の有無を見る
security find-generic-passwordで、Claude Code-credentialsの項目があるかを確かめます。 - 4
ファイルの有無を見る
~/.claude/.credentials.jsonが作られているかを見ます。ドキュメントによれば、Keychainが書き込みを拒否したときはこのファイルへ保存が切り替わります。 - 5
Keychainが書けるかを見る
別名のテスト項目をCLIから追加して、Keychain自体が書き込み可能かを確かめます。
手順3から5を実行する形は、次のとおりです。
# 項目の有無(-w を付けると認証情報そのものが画面に出るので付けない)
security find-generic-password -a "$(whoami)" \
-s "Claude Code-credentials"
# フォールバック先のファイル
ls -l ~/.claude/.credentials.json
# Keychainが書けるかの確認(テスト項目は後で削除)
security add-generic-password -a "$(whoami)" \
-s "test-write" -w "testvalue"
security delete-generic-password -a "$(whoami)" \
-s "test-write"報告者は項目の確認に-w付きのコマンドを使っています。-wは値を出力する指定なので、存在確認だけなら外したほうが画面やスクロールバックに認証情報が残りません。
結果の読み方は、次の表のとおりです。
| 項目 | ファイル | doctorの警告 | 読み方 |
|---|---|---|---|
| なし | ファイルなし | doctorの警告あり | 読み方Issueと同じ状態。保存に失敗している |
| なし | ファイルあり | doctorの警告あり | 読み方Keychainを拒否されてファイルへ切り替わった状態 |
| あり | ファイルなし | doctorの警告なし | 読み方保存はできている。読み出し側を疑う |
| あり | ファイルあり | doctorの警告なし | 読み方二重に残っている。/logoutで一度消してから/loginをやり直し、どちらに書かれるかを見る |
| なし | ファイルなし | doctorの警告なし | 読み方Keychainは書けるのに項目がない。CLAUDE_CONFIG_DIRの違いや環境変数での認証を疑う |
「項目あり・ファイルなし」の行は、後述する別の症状に当たります。表は報告とドキュメントの記述を組み合わせた目安で、Issueの報告者がファイルの有無を書いているわけではありません。
CLAUDE_CONFIG_DIRを設定している場合は、ファイルの場所もKeychainの項目もそのディレクトリ単位になります。項目を探して見つからないときは、この変数を先に疑います。
使える回避策とその限界
報告者と同じ症状の人が書き込んだ回避策は、claude setup-tokenで長期トークンを発行し、環境変数CLAUDE_CODE_OAUTH_TOKENに渡す方法です。
claude setup-token
# 表示されたトークンを、シェルの設定ファイルで渡す
export CLAUDE_CODE_OAUTH_TOKEN=<表示されたトークン>ドキュメントでは、このコマンドはCIやスクリプト向けの手段で、有効期間1年のトークンを画面に表示するだけで、どこにも保存しません。環境変数はシェルの起動のたびに読み直されるので、~/.zshrcなどに入れる必要があります。
トークンを~/.zshrcに平文で置くと、そのファイルを読めるプロセスや、うっかり共有した設定ファイルから漏れます。ls -l ~/.zshrcで自分以外に読み書き権限がないかを確かめ、chmod 600 ~/.zshrcで絞っておくと安心です。Keychainが書き込みを拒否したときのフォールバック先である~/.claude/.credentials.jsonは、ドキュメントによればファイルモード0600で保存されます。トークンを置くファイルも、それに揃える形です。setup-tokenの節には、発行済みトークンを失効させる手順の記載がありません。漏れた疑いがあるときは、設定ファイルから該当行を消し、claude setup-tokenで新しく発行し直します。
ただし、うまくいかなかった報告もあります。
- 報告者自身の評価では、このトークンで得られるスコープは
user:inferenceだけで、user:profileが欠けている - 別の利用者は、環境変数にトークンを手動で入れても
API Error: 401 Invalid bearer tokenが続いたと書いている
したがって、回避策は誰にでも通るとは限りません。--bareを付けたスクリプトはCLAUDE_CODE_OAUTH_TOKENを読まないので、その場合はANTHROPIC_API_KEYかapiKeyHelperが要ります。/loginを実行しても、環境変数が残っている限り次のセッションではそちらが読まれます。
同じ見た目の別の症状との見分け方
「ログインしたのに未ログイン」という見かけは、原因が複数あります。#70077のコメントには、読み出し側の失敗を示す報告もあります。
2026年9月8日のコメントは、Tahoe 26.6.2、Claude Code 2.1.236、Homebrew caskでの再現です。[keychain] readAsync failed; not caching a null lineのログが出て、再起動しても続き、Keychainの項目自体は存在して正常に見えるとのことでした。書き込みに失敗するIssueとは、項目が残っている点で逆の状態です。
エラー一覧の「Not logged in」の節は、Not logged in · Please run /loginを「このセッションに有効な認証情報がない」状態と説明しています。同じ設定ディレクトリを使う別ウィンドウでログインすると、対話セッションが自動でそのログインを使い始めるとも書かれています。ただしv2.1.286より前のmacOSでは、別ウィンドウでログインしてもメッセージが出続けることがあり、その場合はセッションを再起動します。別ウィンドウで/loginを済ませたあとに残る未ログイン表示は、この挙動の可能性があります。
また、変更履歴には、近い名前の修正があります。
| バージョン | 修正の内容 |
|---|---|
| v2.1.290 | 修正の内容macOSで、Keychainが新しいログインを拒否し、古いログインも消せなかったときに、/loginが成功と報告する不具合を修正 |
この修正が#70077の症状に効くかどうかは、Issueに書かれていません。Keychainが拒否したのに成功と表示する、という点が似ているだけです。v2.1.290より古いバージョンを使っているなら、まず更新してから同じ手順で調べ直す価値はあります。
ほかの原因は次の記事が扱っています。許可ダイアログが繰り返し出る症状はClaude Desktopでキーチェーンの許可を毎回求められる原因と対処、並行セッションの競合による再ログインはClaude Codeで何度もログインを求められる原因と対処法、認証画面がループするときはClaude Codeでログインがループする問題が扱っています。
Keychainを直す手順とIssueの状況
doctorがKeychainの警告を出している場合は、ドキュメントの復旧手順が使えます。security unlock-keychainでロックを解除し、効かなければKeychain Accessでloginキーチェーンのパスワードをアカウントのパスワードに合わせ直します。そのあと/logoutと/loginを実行します。
/logoutは保存済みの認証情報をすべて消します。MCPサーバーのログインとプラグインの機密値も対象なので、再認可と再入力が前提です。
#70077の報告者は、ロック解除を試しても変わりませんでした。この手順で直るのは、ロックやパスワードのずれが原因の人です。報告者のように手順が効かない場合は、回避策かIssueの更新を待つ形になります。
Issueには、重複の可能性があるとして#63919、#65466、#44585が自動コメントで挙げられました。3件とも「not planned」で閉じられています。#70077は報告者が重複ではないと反論して残り、最新のコメントは2026年9月8日です。同じ症状なら、Issueに環境と再現手順を追記するのが開発側に届く経路になります。
ログイン方法そのものの選び方はClaude Codeログイン方法3種の使い分けにまとめています。