GitHub DesktopのAuthentication failed・Bad credentialsを直す
この記事の結論
GitHub Desktopのログで認証失敗を分類し、ブラウザー再認証、リモートURL、リポジトリ権限とSSH鍵を確認します。FetchとPushを分け、ローカル作業を残して復旧します。
一般的な切り分けガイドです。特定の不具合が現在発生しているという告知ではありません。
対象製品・影響範囲
- 製品
- GitHub Desktop
- 対象バージョン・条件
- GitHub Desktop for Windows and macOS
- 関連するエラーコード・識別子
- Bad credentialsempty tokenRepository not found
発生する症状
- PushやCloneで認証に失敗する
- Bad credentialsまたはempty tokenがログに出る
原因・発生条件
ブラウザー認証をやり直し、ログから資格情報エラーと権限不足を区別します。
作業前の準備
- 作業前に当日のGitHub Desktopログ、remote URL、ブラウザーでのアクセス結果を記録・保全します。
- 変更は一項目ずつ行い、各段階で元の症状を再現して結果をメモします。
この操作の注意点
- 確認対象と無関係な設定やデータをまとめて削除しません。
- 診断記録には個人情報や認証情報を含めず、当日のGitHub Desktopログ、remote URL、ブラウザーでのアクセス結果のうち必要な範囲だけ共有します。
使用するツール・公式ページ
この手順の設定名、制限事項、更新された分岐を公式ページで確認できます。
具体的な操作手順
［Help］→［Show Logs in Explorer/Finder］で当日のログを開きます。
Repository not foundは資格情報破損ではなく権限や移動・削除の可能性があります。
Bad credentialsとempty tokenは保存資格情報の問題を示すため再サインインが適切ですが、Repository not foundに同じ処置を繰り返しても権限は付与されません。
GitHub Desktopで失敗したリポジトリを選び、［Repository］→［Repository settings］→［Remote］でURLを控えます。その後［Help］→［Show Logs in Explorer/Finder］を開きます。
Desktopでサインアウトし、ブラウザー認証してDesktopへ戻る流れを最後まで完了します。ブラウザーで複数アカウントを使う場合は認可画面のユーザーを確認します。別アカウントのまま承認すると、ログインは完了しても必要な非公開リポジトリへアクセスできない場合があります。
Windowsは［File］→［Options］→［Accounts］、macOSは［GitHub Desktop］→［Settings］→［Accounts］でSign Outします。
作業ツリーの未コミット変更は消えませんが先に保存します。
Continue With Browser後、ブラウザーがDesktopへ戻る許可を求めたら正規のgithub.comまたはEnterpriseホストであることを確認します。
GitHub EnterpriseではGitHub.comと接続先が異なります。会社のサーバーURLと対象アカウントを照合し、同名リポジトリをGitHub.com側で探し続けないようにします。組織の認証要件に従い、パスワードやトークンをリモートURLへ埋め込んで共有しないでください。
同じAccounts画面のSign Intoを選び、Continue With BrowserからGitHubへサインインし2FAを完了します。
GitHub Desktopはユーザー名とパスワードを直接入れる方式をサポートしません。
組織がSAML SSOを要求する場合はブラウザー側で組織認可も完了します。個人アカウントへのログイン成功だけでは対象リポジトリへ届きません。
Fetchが成功してPushだけ失敗する場合は最終エラーから書き込み権限やブランチ規則を確認します。認証不良として全資格情報を削除する前に、そのブランチへの直接書き込みが許可されているか確認します。未pushコミットを残し、許可されたブランチから提案する手順へ切り替えます。
GitHub.comとEnterpriseのボタンを取り違えていないか、ブラウザーで対象リポジトリを開けるか確認します。
SSH URLのリポジトリは有効なSSH鍵かHTTPSへのURL変更が必要です。
［Repository］→［Repository settings］→［Remote］でURLを確認します。HTTPS接続のDesktopとSSH形式のsubmoduleでは認証経路が異なります。
この手順で使う公式リンク
- GitHub Desktop 公式トラブルシューティング
この手順の設定名、制限事項、更新された分岐を公式ページで確認できます。
- GitHub Desktop 公式トラブルシューティング
Help → Show Logs in Explorerでエラーが出た日のログを開き、Bad credentials、Repository not found、Permission denied (publickey)を区別します。画面の「失敗」だけでは保存済み認証、閲覧権限、SSH鍵のどれが原因か判断できません。
対象リポジトリのリモートURLがHTTPSかSSHかを確認します。ブラウザーでGitHubへログインできてもSSH鍵が使える証拠にはならず、Desktopでサインインし直してもSSHの問題が残る場合があります。
Repository not foundではブラウザーの同じアカウントでそのリポジトリへアクセスできるか確認します。名前変更・削除・所属権限の変更もあり得るため、認証情報を次々作り直す前にURLと所有者を照合します。
ブラウザー認証後はDesktopへ戻り、対象アカウントの表示を確認してFetch originを試します。取得に成功しても書き込み権限は別なので、pushだけ失敗する場合はブランチ保護や権限のエラーを読みます。
共有するログからトークン、非公開リポジトリ名、個人用パスを除きます。再認証のためにローカルリポジトリを削除する必要はなく、未pushのコミットと作業ファイルを保持します。
改善したか確認する
- Fetch後に小さいコミットをPushし、Desktop再起動後も再認証を求められないことを確認する
- 問題の操作以外の基本機能も確認し、修正による副作用がないことを確かめます。
改善しない場合・設定を戻す場合
- Repository not foundは所有者へ権限を、SSH publickeyは組織手順の鍵登録を依頼する
- 回避策で作業を続ける場合も、原本やアカウントデータを別の場所へ保全します。
このガイドの適用範囲
対処ガイド — GitHub Desktopのログで認証失敗を分類し、ブラウザー再認証、リモートURL、リポジトリ権限とSSH鍵を確認します。FetchとPushを分け、ローカル作業を残して復旧します。
掲載内容は2026-10-13の情報確認に基づきます。以降の変更は公式出典でご確認ください。
よくある質問
PATをパスワード欄へ入れますか？
Desktopの通常認証はContinue With Browserを使います。
Repository not foundは再ログインで直りますか？
権限不足や名称変更なら管理者または所有者の対応が必要です。
再ログインするとローカル変更は消えますか？
再認証はリポジトリの削除ではありません。未コミット編集と未pushコミットを確認し、再認証と同時に別の破棄操作をしないようにします。認証修復のためにDiscard Changesやフォルダー削除を行う必要はありません。
ブラウザーで見られるのにPushできません。
閲覧権限と書き込み権限は別です。Pushのエラー全文を読み、ブランチ保護や組織権限なら管理者へ確認します。HTTPSとSSHの違いも調べ、ブラウザーへログインできたことだけでSSH鍵の正常性を判断しません。
出典・情報の更新
- 主な出典の更新・解決日
- 公式ページで日付を特定できないため記載していません
- 本サイトの確認日
- 2026-10-13
公式情報を日本語で整理しています。メニュー名は製品の表示言語や版によって異なる場合があります。確認日は障害の発生日を意味しません。編集方針