まず、この表示が自分のケースかを切り分けます。Issue #67087 では、Claude Desktop が
GitHub CLI authentication expired. Run
gh auth loginto refresh pull request status.
というバナーを繰り返し出していた一方で、同じセッション内で gh auth status、gh api user、gh pr status が成功していました。コメントでは、main.log にその日の gh/auth 関連の [error] がなく、LocalSessions.getPrChecks のポーリングも失敗していない、と報告されています。つまり、少なくともこの issue では「本当に期限切れの認証情報が壊れている」という単純な話ではありませんでした。
もう一つの issue #84214 は、少し違う形です。GitHub CLI を別用途で入れただけなのに、Claude Desktop 側の PR 状態機能が有効になり、結果として「GitHub CLI authentication expired」と出続けた、という報告です。投稿者は gh auth status で
You are not logged into any GitHub hosts
と返ってきたと書いています。ここでも、期限切れというより「そもそも Claude が GitHub CLI の存在を見てしまい、認証済みでない状態をエラー扱いした」ように見えます。
手元で確認できる一次情報は、現時点では環境情報だけです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-12T08:50:54+09:00
この出力だけからは、問題の有無も再現条件も判断できません。したがって、ここでは「この症状が出たら認証が壊れている」とは言えません。少なくとも issue 上では、gh の資格情報が有効でもバナーが残る例と、gh が未認証でも同じ文言が出る例の両方が出ています。
現時点で言えるのは、authentication expired という文言が、そのまま実際の期限切れを意味していない可能性がある、ということです。gh auth status が成功しているのに同じ表示が出るなら、#67087 とかなり近い症状です。gh を入れた覚えはあるが Claude で GitHub 連携を使うつもりがないのに出るなら、#84214 に近いです。
issue 内には、原因候補として「Claude が gh の別インストールを見ているのではないか」という指摘もあります。ただし、これはコメントの推測であって、手元の実測で裏が取れているわけではありません。逆に、別コメントでは「環境変数を空にして認証トークンを取りにいく実装がある」とする解析も出ていますが、これも今回の一次情報としては確認できていません。ここでは断定しません。
いま取れる行動は、まず gh auth status を自分の環境で確認し、同じタイミングで Claude Desktop の表示を見比べることです。gh 側が有効なのに banner だけ残るなら、ユーザー側の認証やトークン更新で直る類ではない可能性があります。gh が未ログインなら、表示は不正確でも実際に GitHub 連携は使えない状態です。
この症状については、少なくとも issue ベースでは未解決寄りです。gh auth login を促す文言が出ても、それが本当に必要かどうかは gh auth status の結果と突き合わせて判断するのが安全です。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-12T08:50:54+09:00