この文言が出ているなら、少なくとも issue 上では「GitHub 側の認可はあるように見えるのに、Claude 側のアクセス確認で落ちている」ケースが混ざっています。
報告は 2 件とも解決済みですが、原因の切り分けは少しややこしく、claude.ai の設定画面で GitHub をつなぎ直しても直らない例が出ています。対象になっているのは #56988 と #48769 です。
まず切り分けたいのは、何を使って失敗しているかです。issue を読む限り、同じエラー文でも少なくとも次の 2 系統がありました。ひとつは Claude Code mobile の remote control で、private repository に対して即座に失敗する例です #56988。もうひとつは remote agent の trigger 実行で、github_repo_access_denied とともに HTTP 400 が返る例です #48769。
実際の報告では、どちらも「GitHub を re-authorize してみたが直らない」とされています。たとえば #56988 では、claude.ai web settings で GitHub account を connect したあと mobile app から private repo の session を remote control しようとすると、次のエラーが出ます。
메시지 전송 실패
GitHub repository access check failed — re-authorize GitHub in settings
そして issue 本文では、再認可しても解消しなかったと書かれています。
#48769 でも状況は似ています。RemoteTrigger API で action: "run" を呼ぶと、HTTP 400 とともに次が返ります。
{"reason":"github_repo_access_denied","message":"GitHub repository access check failed — re-authorize GitHub in settings"}
この issue で特に重要なのは、案内される先が settings UI なのに、そこで根本解決にたどり着けないという点です。コメントには、claude.ai/settings/connectors で GitHub connector を disconnect / reconnect しても直らなかった、という報告がありました #48769。つまり、少なくともこの報告群では「GitHub connector をつなぎ直せば復旧する」とは言えません。
筆者の環境では、この件に関連する設定ファイルは見つかっていません。実際に確認できたのは次の出力です。
[settings_structure]
~/.claude/settings.json: (存在しない)
/mnt/vda5/git/papoo/newsbot_openai/.claude/settings.json: (存在しない)
/mnt/vda5/git/papoo/newsbot_openai/.claude/settings.local.json: (存在しない)
このため、少なくとも手元の検証では、settings.json の実ファイルに対して「このキーを変えれば直る」と案内できる根拠はありません。分からないことは分からないままにしておくと、この症状は「Claude の設定だけで閉じた問題」ではなく、issue コメントで指摘されているように GitHub OAuth と GitHub App installation の層が噛み合っていない可能性があります。ただし、これは issue コメントの推測を踏まえた見方であって、筆者環境で実証したものではありません #48769。
読者が自分のケースかどうかを見分けるなら、次のどちらかに当てはまるかで考えるのが近道です。private repository で mobile remote control を始めた瞬間に失敗するなら #56988、remote agent の run や schedule 系の trigger で github_repo_access_denied が返るなら #48769。どちらも、少なくとも報告上は「GitHub を reconnect しても直らない」点が共通しています。
現時点で言えるのはここまでです。解決策が settings UI 内に見つからない、というのが issue の主題でしたし、実際に提示された再認可手順でも復旧しない報告が残っています。したがって、この記事では「このエラーが出たら必ずここを直せばよい」とは書けません。確認できているのは、エラー文、失敗する経路、そして settings 由来の再接続では解消しない例がある、という事実だけです。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-10-11T08:54:25+09:00