The token in GH_TOKEN is invalid が出るときにまず見るところこの症状は、少なくとも #106752 と #103761 の報告で、どちらも「GitHub 連携は緑なのに、クラウドセッションの中では gh auth status が The token in GH_TOKEN is invalid を返す」という形で出ています。見た目は GitHub 側の接続が生きていそうでも、実際にはセッション内で使われるトークンが通っていない、という切り分けになります。
#103761 の報告では、connector page 上では GitHub アカウント接続や GitHub App のインストールが緑で、リポジトリのステータスチェックも通っていました。それでもクラウドセッション内では次のようになっています。
gh auth status → "The token in GH_TOKEN is invalid"
git ls-remote https://github.com/<owner>/<repo>.git → "fatal: could not read Username for 'https://github.com': terminal prompts disabled"
#106752 でも、再作成したスケジュールタスクの最初の実行でリポジトリが作業ディレクトリに見えず、git clone が失敗し、その後 gh auth status で同じ系統のエラーに落ちています。報告文から読める範囲では、同じタスク構成でそれ以前の実行は普通にリポジトリへアクセスできていました。つまり、少なくとも一部のケースでは「設定そのものが最初から壊れている」というより、セッションごとに渡される認証情報がうまく機能しない瞬間があるように見えます。ただし、ここは issue から確定できる範囲に限られます。
代表 issue のコメントでは、次の点がはっきり書かれています。GitHub App のインストールが緑であることは、あくまでインストールが存在することを示すだけで、サンドボックスに渡されるトークンまで保証しない、という整理です。また gh auth status が GH_TOKEN のトークンを invalid と言うのは、その変数自体はセットされていて、値が拒否されたことを意味する、とされています。ここまでは issue の中で確認できます。
現時点で言えるのは、「GitHub 側の接続表示が緑」でも安心できず、実際にはセッション内の GH_TOKEN が無効扱いになっている可能性がある、ということです。逆に言うと、gh auth status の結果がこのエラーなら、問題の中心はローカルの git 設定そのものではなく、セッションに渡された認証情報のほうにあると考えるのが自然です。
筆者の環境では、検証時点の情報は次のとおりです。出力として確認できたのはこれだけで、追加の再現結果はありません。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-03T08:56:28+09:00
この症状に当たったら、まずは自分のケースが issue の報告と同じかを見ます。gh auth status が The token in GH_TOKEN is invalid になっているか、GitHub の接続画面は緑でもセッション内では失敗するのか、そこが一致しているかどうかです。もし一致しているなら、少なくとも報告済みの症状クラスタには入っています。解決手順までは issue 群だけでは確定していないので、ここでは断定しません。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-11-03T08:56:28+09:00