Claude Media
Claude Codeの「No LLM gateway」の原因とclaude respawnでの直し方
Claude CodeTips

Claude Codeの「No LLM gateway」の原因とclaude respawnでの直し方

別フォルダからdispatchやattachしたバックグラウンドセッションに「No LLM gateway」と出る理由と、settingsのenvブロックに置く方法・claude respawnで戻す方法の2通りを手順で示します。

読了目安 約12分

バックグラウンドセッションにNo LLM gatewayと出たら、そのセッションはLLMゲートウェイのANTHROPIC_BASE_URLを受け取れていません。リクエストはゲートウェイに届かず失敗します。直し方は2通りです。ゲートウェイの設定をsettingsファイルのenvブロックへ置いてclaude respawn <id>を実行するか、ゲートウェイを書き出したシェルから、メッセージが指すフォルダでclaude respawn <id>を実行します。

「No LLM gateway」は何が起きたサインか

メッセージは、Claudeの返答の代わりに会話の中へ表示されます。セッションIDとフォルダ名が入った形で、おおよそ次の文面です。

No LLM gateway: a gateway set in your shell isn't passed to a session opened from another folder. To fix, run `claude respawn abc12345` from ~/project in another terminal where your gateway is set, or set ANTHROPIC_BASE_URL and its API key or token in a settings file's env block.

そのセッションにattachしている間は、プロンプトの下に短い形が出ます。

No LLM gateway: opened from another folder · respawn from ~/project

原因は、シェルでANTHROPIC_BASE_URLにゲートウェイを設定した状態で、メッセージが指すフォルダとは別のフォルダからセッションをdispatchした、起こした、または再起動したことです。Claude Codeは、シェルのゲートウェイ設定を別フォルダのセッションへ渡しません。ゲートウェイを意図せず迂回する事態を避けるための挙動と読めますが、エラーリファレンスはその理由まで説明していません。

バックグラウンドセッションの全体像はagent viewの解説にまとめています。ゲートウェイそのものの設計はClaude Code LLM gatewayとはが扱います。

どんな操作で出るか

シェルで書き出したゲートウェイが、バックグラウンドセッションへ届く場合と届かない場合は、セッションを動かす場所で分かれます。

操作シェルのゲートウェイは届くか
←または/backgroundで、いま使っているセッションを裏に回すシェルのゲートウェイは届くか届く
いまいるディレクトリへdispatchするシェルのゲートウェイは届くか届く
いまいるディレクトリで、止まったセッションにattachまたは返信して起こすシェルのゲートウェイは届くか届く
いまいるディレクトリでclaude respawnするシェルのゲートウェイは届くか届く
@<repo>で別のリポジトリへdispatchするシェルのゲートウェイは届くか届かない
別のディレクトリからclaude attachして、止まったセッションを起こすシェルのゲートウェイは届くか届かない

上の4行が届くのは、さらに条件があります。supervisor(バックグラウンドセッションを預かる常駐プロセス)自身が、同じゲートウェイを書き出したシェルから起動されていることです。ゲートウェイと一緒に書き出したANTHROPIC_CUSTOM_HEADERSと認証情報も、同じ条件で届きます。

典型例は、親ディレクトリでclaude agentsを開き、@<repo>で子のリポジトリにdispatchする使い方です。agent viewはその場で子のリポジトリへセッションを作るため、メッセージが指すフォルダと現在のフォルダが食い違います。

別フォルダへ新しいセッションを作る方法は、agent viewのドキュメントに3つ載っています。

  • そのフォルダでclaude agentsを開く
  • 親ディレクトリでclaude agentsを開き、@<repo>で子のリポジトリを指す
  • シェルでそのフォルダへcdし、claude --bg "<prompt>"を実行する

ゲートウェイの観点で分かれるのは2つ目だけです。1つ目と3つ目はセッションを作る場所と実行する場所が一致するので、上の表の「いまいるディレクトリへdispatchする」に当たり、supervisorの条件を満たせば届きます。

届いた場合も、ゲートウェイはそのセッションの実行中プロセスにだけ渡され、ディスクには書かれません。次に別フォルダからセッションが再起動されれば、また届きません。

BedrockやVertex AI経由の場合

クラウドプロバイダの前にゲートウェイを置いている場合も、考え方は同じです。ディスパッチ元のシェルがプロバイダを選び、そのゲートウェイのエンドポイントを認証バイパス用のフラグと一緒に書き出していると、Claude Codeはその組をセッションへ転送します。転送の条件はANTHROPIC_BASE_URLと同じで、ANTHROPIC_CUSTOM_HEADERSも一緒に渡ります。

ドキュメントの例はVertex AIです。CLAUDE_CODE_USE_VERTEX=1、ANTHROPIC_VERTEX_BASE_URL、CLAUDE_CODE_SKIP_VERTEX_AUTH=1を書き出したシェルから、いまいるディレクトリのセッションを動かせば転送されます。つまり、別フォルダへ@<repo>でdispatchすれば、ANTHROPIC_BASE_URLと同じ理由でエンドポイントが届かない可能性があります。この場合に出る表示はNo LLM gatewayとは限らないので、ドキュメントに載っている条件の範囲で読んでください。プロバイダの選択そのもの(CLAUDE_CODE_USE_BEDROCKやCLAUDE_CODE_USE_VERTEX)とPATHは、ディスパッチ元のシェルのものがセッションに引き継がれます。

直し方は設定の置き場所で決まる

2通りの直し方は、ゲートウェイをどこに置いているかで選びます。

くらべる

ゲートウェイの置き場所で選ぶ直し方

恒久的

settingsのenvブロックに置く

~/.claude/settings.jsonか、そのセッションのプロジェクトの.claude/settings.local.jsonにANTHROPIC_BASE_URLと認証情報を書きます。そのあと、任意のフォルダでclaude respawn <id>を実行します。

その場しのぎ

シェルのゲートウェイで再起動する

ゲートウェイを書き出したターミナルで、メッセージが指すフォルダへcdし、メッセージに書かれたclaude respawn <id>を実行します。

settingsのenvブロックに置く

agent viewをゲートウェイ前提のプロジェクトで使うなら、こちらを選ぶのが基本です。envブロックの形は、どちらのファイルでも同じです。

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://llm-gateway.example.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-gateway-key"
  }
}

認証情報の変数名は、ゲートウェイが発行した資格情報の種類で決まります。APIキー型ならANTHROPIC_API_KEYに差し替えます。

置き場所には注意点があります。ゲートウェイ接続ガイドは、プロジェクトの.claude/settings.jsonに認証情報を置かないよう警告しています。このファイルはコミットされ、クローンした全員に共有されるためです。プロジェクト単位で置くなら.claude/settings.local.jsonを使い、手で作った場合は自分でgitignoreに加えてから認証情報を書きます。この仕組みはsettings.local.jsonがgitignoreされる仕組みで詳しく扱っています。

置いたあとは、セッションのIDを指定して再起動します。

claude respawn abc12345

claude respawn <id>は、動いているセッションも止まったセッションも再起動します。保存された会話があれば、そこから再開します。実行するフォルダはどこでも構いません。再起動したセッションがsettingsファイルを読むので、ゲートウェイが届きます。動いているセッション全部を一度にゲートウェイへ載せ替えたいときは、claude respawn --allで全件を再起動できます。

同じ変数をシェルとsettingsの両方に書いた場合は、settingsの値が使われます。どちらの値が効いているかは、セッション内で/statusを実行すると確かめられます。ゲートウェイ接続ガイドによると、/statusにはClaude Codeが使っているベースURLと認証情報の取得元が出ます。表示されたベースURLがゲートウェイのものなら届いていて、そうでなければ、そのセッションにはまだ渡っていません。

シェルのゲートウェイのまま再起動する

settingsへ書きたくない場合は、ゲートウェイを書き出したターミナルから再起動します。メッセージ自身がfrom ~/projectのようにフォルダを教えてくれるので、そこへ移動します。

# ゲートウェイを書き出したターミナルで実行する
export ANTHROPIC_BASE_URL="https://llm-gateway.example.com"
export ANTHROPIC_AUTH_TOKEN="sk-gateway-key"
cd ~/project
claude respawn abc12345

これで直らないときは、supervisorの側を疑います。シェルのゲートウェイが届くのは、supervisorが同じゲートウェイを書き出したシェルから起動された場合だけでした。supervisorが別のシェルから起動されていたなら、まず止めて、いまのターミナルから起動し直します。

claude daemon stop --any --keep-workers
claude agents

--keep-workersを付けると、動いているセッションは残ったまま次のsupervisorに引き継がれます。止めたあと約1分以内にclaude agentsかclaude --bgを実行すると、新しいsupervisorがいまのシェルの環境で立ち上がります。そのうえで、もう一度claude respawn <id>を実行します。supervisorの扱いはbackground serviceが応答しないときの直し方に詳しくあります。

どちらを選ぶか

ゲートウェイ経由での利用が日常なら、settingsのenvブロックに寄せたほうが再発しにくい構成です。ゲートウェイ接続ガイドも、バックグラウンドエージェントが必ずゲートウェイを通る必要があるなら、シェルではなくsettingsファイルを使うよう案内しています。

一方、ゲートウェイを一時的に試しているだけなら、シェルの書き出しのまま、該当フォルダでrespawnする手でも足ります。ただしこの場合は、別のリポジトリへdispatchするたびに同じメッセージが出る可能性があります。

接続ガイドが勧めるのは、シェルで接続を確かめてから値をsettingsに移す順序です。手順はClaude CodeをLLMゲートウェイに接続する方法にあります。

古いバージョンでの見え方と似たエラーとの違い

No LLM gatewayの表示はv2.1.302からです。それ以前のバージョンでは、同じ状況でNot logged in · Please run /loginのようなサインインのエラーが出ていました。フォルダ名も示されなかったため、ログインし直しても直りません。ゲートウェイ経由で使っていてサインインを求められたら、まずバージョンと、dispatch元のフォルダを疑う価値があります。

似た名前のエラーとの見分け方は次のとおりです。

表示原因直し方
No LLM gateway原因シェルのゲートウェイが別フォルダのセッションへ渡っていない直し方settingsのenvブロックに置く、または該当フォルダでrespawn
Could not resolve authentication method原因supervisorが保存済みの認証情報を持っていない直し方/loginなどを確認し、supervisorを止めて起動し直す

Could not resolve authentication methodは、ゲートウェイではなく認証情報の問題です。claude daemon stop --any --keep-workersのあとにsupervisorを起動し直すところまでは、前節と手順が重なります。

まとめ

No LLM gatewayは、設定の間違いではなく、シェルのゲートウェイが別フォルダのセッションに渡らない仕様が表に出た状態です。ゲートウェイを常用するなら、settingsのenvブロックへ移してclaude respawn <id>を一度実行する。それで同じメッセージはほぼ出なくなります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →