GitHub CLIの期限付きOAuth：コピーしたトークンの寿命を点検する

CLIはログインしたままなのに、昨日から動く補助スクリプトだけが失敗する。古いトークンを保持していないだろうか。2026年10月21日のGitHub発表を機に、まず認証情報が通る経路を整理したい。

確認できた変更：任意で使う更新型認証

v2.103.0からgh auth login --expiringで利用を申請できる。ghは期限付きaccess tokenとローテーションするrefresh tokenを保存し、必要に応じて更新する。既存ログインや手動トークンは従来どおりだ。github.com、ghe.com、GHES 3.23以降が対応し、非対応サーバーでは無期限方式に戻る場合がある。gh auth statusで実際の状態を確認する。

コピーした文字列は自動では更新されない

GitHubはgh auth tokenを一度取得して後で再利用するスクリプトに注意を促す。外部の利用側は必要な時に新しく取得する。起動時の成功は後続処理の有効性を保証しない。refresh tokenの漏えいリスクも残り、短い有効期間は最小権限や失効処理の代わりにはならない。

チームで試す点検順序

バージョン、ホスト、ファイル・環境変数・拡張機能にコピーする経路を記録する。秘密値ではなく管理者と再取得時点を残す。検証環境で同じ読み取りを起動直後と時間経過後に比較し、期限・権限・ネットワークを切り分ける。HTTPS gitではgh auth setup-gitとgit 2.46以降の推奨を検討する。実設定の変更は別途レビューする。

先に改修が必要な経路もある

長期間有効なトークンに依存する連携について、公式発表も参加の保留を勧める。担当者と再検討日を記録して放置を防ぐ。開発者OAuthとCIのGITHUB_TOKENを同一視しない。一つのフラグで全自動化の権限・寿命・失効方法が統一されるわけではない。導入版の対応状況を再確認する。

開発者の会話にある「ログイン維持」を二つに分ける。管理側は更新できるか、利用側は更新後の値を受け取るか。本稿はコミュニティの障害率を測定したものではない。実際の利用経路を一つ図にすれば、キャッシュ所有者と試験範囲が明確になる。

公式資料と追加確認

GitHub Changelog · Expiring OAuth preview

GitHub Docs · CLI authentication

バージョン、ホスト、キャッシュ管理者、再取得時点、検証結果のみ記録し、秘密値は残さない。