Cloud gateway session expiredの原因と対処 — gatewayログインエラー3種
Claude apps gatewayのログインエラー3種を原因別に切り分けます。Cloud gateway session expiredなど、/loginで直るものと管理者の対応が要るものの境目を示します。
Claude apps gatewayでサインインした環境では、ログインまわりのエラーが3種類出ます。Cloud gateway session expired、Sign-in timed out while waiting for you to continue、Gateway refused the requestです。見た目はどれも「ログインできない」ですが、直す人も直し方も違います。
先に結論を表にします。
| 表示 | 原因 | 直す人 | /loginで直るか |
|---|---|---|---|
Cloud gateway session expired — run /login to reconnect. | 原因保存済みのゲートウェイセッションが期限切れ、またはゲートウェイが受け付けなくなった | 直す人開発者(繰り返すなら管理者) | /loginで直るか直る |
Sign-in timed out while waiting for you to continue. Try again. | 原因確認画面を開いたまま、サインインの有効期限が切れた | 直す人開発者 | /loginで直るか直る(期限内に確認する) |
Gateway refused the request · signing in again won't change this … | 原因ゲートウェイか上流が403で拒否した | 直す人管理者 | /loginで直るか直らない |
Claude apps gatewayそのものの導入は基本の使い方にあります。ここでは、すでに動いているゲートウェイで出たエラーを読み解きます。
Cloud gateway session expiredが出る2つの経路
このメッセージは、端末に保存したゲートウェイセッションが期限切れで更新もできない場合に出ます。ゲートウェイ側がそのセッションを受け付けなくなった場合も同じです。後者の典型は、ゲートウェイの署名用シークレット(session.jwt_secret)を置き換えた直後です。
Cloud gateway session expired — run /login to reconnect.出方は起動の仕方で変わります。
- 対話起動の開始時: ゲートウェイからサインアウトした状態でセッションが開きます
- セッションの途中: ゲートウェイの認証情報が期限切れになり、更新できなかったときに同じ行が出ます
- 非対話の実行・バックグラウンド・
claude auth以外のサブコマンド: 次の別の文言で終了します
Cloud gateway <url> no longer accepts this session. Start `claude` and sign in again with /login.終了メッセージの<url>には、サインインしているゲートウェイのアドレスが入ります。
開発者の直し方
- 実行中のセッションで
/loginを打ち、ブラウザでのサインインを終える - 非対話の起動で出たときは、同じ環境で
claudeを起動して/loginを済ませてから、コマンドを再実行する
# 非対話で止まったときの復旧(同じ環境で)
claude # 対話起動
# セッション内で /login → ブラウザで認証
# 認証後に終了して、元のコマンドを再実行CIやリモート開発機から使う構成の組み方はCIやリモート開発機から使う方法にまとめています。
繰り返し出るなら管理者側の原因を疑う
/loginで直るのは、その1回の期限切れだけです。同じ人がsession.ttl_hoursごとに繰り返すなら、サーバー側に理由があります。ゲートウェイのトークン寿命は既定で1時間で、IdPがリフレッシュトークンを出していれば、CLIが期限前に静かに更新します。更新が成立しない条件は主に3つです。
| 状況 | 何が起きているか | 管理者の対処 |
|---|---|---|
| JWTシークレットを旧値を残さず置き換えた | 何が起きているか稼働中の全セッションが一斉に無効になる | 管理者の対処次回から、新シークレットをsession.jwt_secret配列の先頭に足し、ttl_hours+余裕のあとに旧値を外す |
IdPのスコープからoffline_accessを外している | 何が起きているかリフレッシュトークンが出ず、ttl_hoursごとにブラウザ認証をやり直す | 管理者の対処offline_accessを使えるようにする。使えないならttl_hoursを8か12に上げる |
| IdPが更新時にid_tokenを返さず、userinfoも更新後のアクセストークンを拒否する | 何が起きているかログにrefresh failed … invalid_token (… at userinfo_no_id_token …)が出て、ttl_hoursごとにこのエラーになる | 管理者の対処v2.1.260以降のゲートウェイでoidc.scope_on_refresh: trueを設定する(PingFederateは下記)。つなぎとしてttl_hoursを上げる手もあるが、失効の猶予が延びる |
3行目の仕組みはこうです。IdPは更新用のリフレッシュトークン自体は受け付けますが、id_tokenを返しません。そこでゲートウェイがuserinfoにユーザー情報を問い合わせ、そこで更新後のアクセストークンが拒否されます。ゲートウェイはtemporarily_unavailableを返すため、Claude Codeはリフレッシュトークンを持ったまま、セッションを更新できません。v2.1.260より前のゲートウェイは、同じ行を(at …)の詳細なしで記録します。ログに詳細が無くても、この原因を除外はできません。
scope_on_refreshが効かないIdPもあります。PingFederateでは、このキーを設定しても挙動は変わりません。代わりに、管理画面の「Applications > OAuth > OpenID Connect Policy Management」にある「Return ID Token On Refresh Grant」を有効にします。Oktaのように、openidを再度求められたときだけid_tokenを返すIdPには、scope_on_refreshが合います。ただし、この設定を入れたあとにscopesへ項目を足すと、IdPが要求より少ないスコープしか許可していない場合、既存セッションの更新もinvalid_scopeで失敗しえます。設定後に更新がtoken_endpointで失敗し始めたら、キーを外します。
IdP自体が止まっている間は事情が違います。更新は「あとで再試行」の応答になり、IdPが戻れば成功します。メンテナンス窓が頻繁なIdPでは、ttl_hoursを長めにする判断材料になります。
ttl_hoursを上げる対処には代償があります。退職者などをIdP側で無効化しても、リフレッシュに失敗して締め出されるまでの猶予が、上げた時間の分だけ延びます。リフレッシュトークンが出せないIdPで8か12にするときも、同じ代償を引き受けます。
JWTシークレットのローテーションは、既存セッションを切らない手順が決まっています。
# gateway.yaml(例)。先頭が署名用、全要素が検証用
session:
jwt_secret:
- "<新しいシークレット>" # index 0 で署名
- "<古いシークレット>" # ttl_hours + 余裕のあとに削除ベアラートークンはJWTシークレットでローカル検証されるので、セッション単位の失効はありません。期限前に全員を追い出せるのは、シークレットを丸ごと置き換える操作だけです。個人のオフボーディングはIdP側で無効化します。ユーザーはリフレッシュに失敗して、ttl_hours以内にこのエラーへ行き着きます。ローテーションの手順はデプロイと運用の記事で詳しく扱っています。
Sign-in timed outは確認画面の放置で起きる
このエラーが出るのは、ゲートウェイが「どのアカウントでサインインしたか」を返す構成だけです。ゲートウェイがトークン応答に任意のemailを載せると、Claude Codeは認証情報を保存する前に、そのアカウントでよいかの確認を求めます。確認を開いたまま放置し、サインイン自体の有効期限を過ぎると、更新に使えるリフレッシュトークンも無いため、何も保存されません。
Sign-in timed out while waiting for you to continue. Try again.直し方は1つです。/loginをやり直し、有効期限が切れる前にアカウントを確認します。
この確認画面の前提は2つあります。
- 確認の動作にはClaude Code v2.1.275以降が必要で、それより古いクライアントは
emailフィールドを無視します claudeバイナリ内蔵のゲートウェイサーバーはemailを返さないため、そのサインインに確認画面は出ません
確認が通ったあとは、/statusでサインイン中のアカウントを確かめられます。
Gateway refused the requestは再ログインでは直らない
3つのうち、このエラーだけは性質が違います。サインインは成立しています。そのうえで、あるリクエストが403で拒否されました。拒否したのは、ゲートウェイ自身か、その背後にある上流です。
Gateway refused the request · signing in again won't change this — check with your gateway administrator · API Error: 403 ...メッセージ自体が「再ログインでは変わらない」と明言しています。/loginを繰り返しても状況は変わらないので、開発者はAPI Error:以降の文字列をそのまま管理者へ渡します。そこにゲートウェイが返した拒否の内容が入っているからです。
v2.1.273より前は、ゲートウェイセッションでの403が汎用のPlease run /loginやFailed to authenticateとして表示されていました。旧バージョンの端末でログインを繰り返しても直らない場合は、実は同じ拒否が原因かもしれません。
管理者が見る場所
403の出どころは大きく2つに分かれます。
- ゲートウェイのアクセス制御:
access_controlのallow_cidrsとdeny_cidrsによる、クライアントIPの許可・拒否です。拒否は監査ログにaccess.deniedとして、理由とクライアントIP付きで残ります。deny_cidrsが先に評価され、allow_cidrsが空でなければ既定で拒否になります - 上流の認可拒否: 上流が返した403を、ゲートウェイがステータスのまま中継します
監査ログはゲートウェイがstderrに1行1イベントのJSONで出します。拒否の調査では、access.deniedとauth.deniedを探します。auth.deniedはユーザーの身元がまだ無い段階の拒否で、理由とクライアントIP、リクエストパスを持ちます。
# 例: Kubernetesで動かしている前提で、拒否イベントだけを抜く
kubectl logs deploy/claude-gateway | grep -E '"(access|auth)\.denied"'access.deniedの理由にはxff_unparseableもあります。前段のプロキシが送るX-Forwarded-Forの値がIPアドレスとして読めないと、本当のクライアントが分からず、リストが適用される場面では403になります。前段にプロキシを置いている構成では、この理由が出ていないか見ます。
上流が返す403の扱いは、全上流が失敗した場合の選び方に注意が要ります。ゲートウェイは複数の上流に切り替えながら試します。すべて失敗したときは、最後の429があればそれを、無ければ最後の401か403を返します。上流の応答をそのまま返すとき、ステータスコードは保たれます。メッセージが残るかはプロバイダー次第です。Anthropic APIが上流なら、エラー本文は開発者までそのまま届きます。Amazon Bedrockなどは、アカウントIDやロールARNがエラー文に含まれうるため、全文はゲートウェイの運用ログにだけ記録されます。開発者の画面に出る文言が薄くても、運用ログには理由が残っています。
起動時にClaude Code may not be enabled for your organizationと403で出るケースは別の経路で、設定取得ルートの前段にあるaccess_controlかプロキシ、WAFが原因です。切り分けはデプロイと運用の記事の障害表にあります。
3つを見分ける手順
画面の文言から入れば、迷いません。
文言からの切り分け
- 1
文言の先頭を読む
Cloud gateway session expired/Sign-in timed out/Gateway refusedのどれかを確認します。 - 2
前の2つは /login を1回
サインインを終えるまで進め、確認画面があれば期限内に承認します。直れば原因は単発の期限切れです。
- 3
同じ人が繰り返すなら管理者へ
ttl_hoursごとに再発するなら、リフレッシュトークンとJWTシークレットの運用を確認します。 - 4
Gateway refused は最初から管理者へ
API Error:以降の文字列を添えて渡します。再ログインは試す価値がありません。
対話起動でforceRemoteSettingsRefreshが未設定のとき、ゲートウェイが401を返すと、同じCloud gateway session expiredの表示でゲートウェイからサインアウトした状態になります。サーバー管理設定を取得する起動時チェックとの関係は強制リフレッシュの記事で扱っています。ゲートウェイ経由で使えない機能の話はfast modeの記事にあり、ログイン方式全体の整理はログイン方法の記事から辿れます。