この表示が出たからといって、gh の認証情報が実際に失効したとは限りません。少なくとも issue #67055 では、デスクトップアプリが重いマルチエージェント処理中にこのトーストを出していましたが、直後に gh auth status はログイン済み、gh api user も 200 を返していました。報告者は、gh auth login を案内どおり実行しても筋の悪い切り分けになると述べています。
同じ系統の報告として #96503 もあり、こちらは GitLab の merge request を開いているのに、ツールチップがやはり
GitHub CLI authentication expired. Run gh auth login to refresh pull request status.
と出る、という内容でした。そこでは gh auth status は github.com に対して正常、glab auth status も gitlab.com に対して正常で、MR の番号・状態・ブランチ自体は glab 側の経路で正しく取れていると書かれています。つまり、表示される文言だけを見て「GitHub CLI の認証が本当に切れた」と決めつけるのは危険です。
手元で実際に確認できたのは環境情報だけです。少なくとも、以下の環境で検証していることは分かります。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-24T08:52:02+09:00
今回の情報だけで言えるのは、症状の見え方が「認証期限切れ」と一致していても、実際には別の失敗を同じ文言に寄せている可能性がある、という点です。issue 側では、gh auth status の失敗やタイムアウト、短時間の API 401、イベントループの詰まり、cwd 関連の spawn 失敗など、複数の経路が同じ "auth" 扱いになっているとされています。ただし、これは issue 報告の範囲での説明であって、こちらでは再現確認まではできていません。
もしこの表示を見たら、まずは「本当に gh の認証が切れたのか」を急いで決めつけず、直後の gh auth status や gh api user の結果がどうなっているかを見たほうがよさそうです。issue #67055 では、表示と実際の状態が食い違っていました。gh auth login をすぐ打つ前に、少なくともそこだけは確認したいところです。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-24T08:52:02+09:00