まず、この症状に当てはまるかを切り分けます。Issue 上では、Claude の GitHub 連携が有効になっていても、private repository にアクセスできず HTTP 404 に見える報告が出ています。たとえば #68517 では、個人アカウント配下の private repo に対して Claude GitHub App を「All repositories」でも「Only select repositories」でも許可し直し、Claude 側の GitHub integration を再接続し、さらに競合しそうな custom GitHub MCP connector まで外しても、なお読めなかったと書かれています。
同じ症状として、GitHub connector は接続済みなのに、repo の追加時にファイルの読み込みや同期が失敗する、あるいは project context には載るのに個別チャットでは失敗する、という報告もありました。コメントには「successfully connected」「all repo permissions given and installed」といった記述があり、それでも動かなかったとされています。つまり、少なくとも issue ベースでは、GitHub 側の権限を見直しただけでは解消しないケースがある、というところまでは確認できます。
一方で、今回の 2 件の中で、HTTP 404 という症状に直接つながるのは #68517 の方です。そこでは「Claude GitHub App が private repo にアクセスできない」という backend index/sync issue として報告されていました。これが権限の付け忘れなのか、同期側の問題なのかは、issue の報告だけでは断定できません。ただ、少なくとも報告者は次を実施済みでした。
これでも読めないなら、現時点では「Claude 側の連携が正常に見えても、裏側の index/sync が private repo を拾えていない」可能性を疑うのが自然です。とはいえ、これは issue から読み取れる範囲の話であって、原因の確定ではありません。
参考までに、関連 issue の流れでは duplicate 扱いのコメントも付いていました。自動で duplicate close された例としては、代表 issue に対して「Found 3 possible duplicate issues」と出たあと、3 日で自動クローズされる旨の案内がありました。今回の症状が同じ系統かどうかは、#68517 の記述を見る限りかなり近いですが、こちらでも完全一致とまでは言えません。
現時点で、この種の HTTP 404 を前にして確認できる実用的な見方はシンプルです。GitHub 上で repo が見えていて、Claude 側で App の権限も再付与済み、integration も再接続済み、それでも private repo だけ読めないなら、ユーザー操作のミスよりも Claude 側の同期・索引の不調を疑うべきです。逆に、public repo まで読めないなら、別の連携断や connector 側の問題もありえますが、その点は今回の issue では裏付けがありません。
最後に、今回の一次情報として確認できた環境出力だけ載せます。原因特定に直結する内容ではありませんが、記事内で使える実測値はこれだけでした。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-01T08:50:38+09:00
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-01T08:50:38+09:00