OpenClawの401認証エラーを直す：invalid bearer tokenとmissing authentication headerの切り分け

OpenClawの401認証エラーは、拒否した相手を確認してから、該当する認証情報だけを修正すると切り分けやすくなります。ダッシュボードに接続できない場合はGatewayの接続認証、チャットを送った後にprovider returned HTTP 401が出る場合はモデル提供元の認証を調べます。Gatewayのトークンを交換しても、モデル提供元のAPIキーは更新されません。

invalid bearer tokenなら選択中のトークンやアカウントを確認し、missing authentication headerなら送信先、認証情報の参照先、実行中の環境を確認します。main agentは動くのに別のagentだけ失敗する場合、全agentにキーを入れ直す必要はありません。現在のOpenClawは共有認証情報を読み取れますが、同じIDのagentローカル設定があると、そちらが優先されます。認証情報の保存仕様

最初に、どこで401が出ているかを確認する

以下の表で、今の症状に合う確認先を選んでください。「トークン」という言葉だけで、すべてを同じ認証として扱わないことが大切です。

チャンネルの401が出ているのにAnthropicのキーを再発行したり、モデルの401に対してGateway認証を無効にしたりすると、原因とは別の設定を変えてしまいます。チャンネルの問題は公式のチャンネル別トラブルシューティング、Gateway接続の問題は次節へ進んでください。

モデルの問題なら、Gatewayが動くマシンで、Gatewayと同じOSユーザー・同じ状態ディレクトリを使って、まず次を確認します。<agentId>は失敗したagentのIDに置き換えます。

openclaw --version
openclaw gateway status
openclaw doctor
openclaw models status --agent <agentId>
openclaw models auth list --agent <agentId>

models auth listは保存済みプロファイルのIDや状態を確認するコマンドで、キーやトークンの本文を表示しません。問題が起きた会話では、別途/model statusを入力してください。CLIの--agentが調べるのは設定されたagentであり、その会話だけのモデル・プロファイル上書きまで調べるわけではありません。公式CLIリファレンス

Gatewayのトークン・デバイス認証が拒否される場合

Gateway接続のエラーは、error.details.codeに沿って直します。共有トークン、デバイスのトークン、承認済み権限は別のものです。

共有トークンが必要な場合、Gatewayホストの対話型ターミナルで次を実行し、表示された値を正しいクライアントに設定します。出力は秘密情報なので、その場で扱い、スクリーンショットや問い合わせ文に貼らないでください。

openclaw gateway auth-token --show

PAIRING_REQUIREDでは、接続したいデバイスと要求された権限を確認してから承認します。<requestId>には一覧に出た該当要求のIDを入れます。

openclaw devices list
openclaw devices approve <requestId>

AUTH_SCOPE_MISMATCHは、デバイスのトークンが認識されても権限が足りない状態です。共有トークンを再発行し続けるより、要求された権限と承認内容を直してください。修正後、同じクライアントで接続できることが成功条件です。その後のモデル呼び出しは別途確認します。現在の公式エラーコード表

invalid bearer tokenは、選択中の認証方式を確認する

invalid bearer tokenは、送信された認証情報が受け付けられなかったことを示す手掛かりです。ただし、この文字列だけでは失効、誤ったアカウント、別プロファイルの選択など、原因を一つに絞れません。エラーを出した提供元と、その会話の実行方式を先に確認します。

この図は切り分けの考え方を示す旧図です。実際に使うコマンドと共有認証情報の扱いは、以下の現行手順を確認してください。

Anthropic APIを使っている場合

API接続を選択しているなら、Anthropic ConsoleのAPIキーを使います。現在のAnthropic向け公式案内は、トークンが失効・取り消しされた場合の新しい構成にはAPIキーを勧めています。既存のsetup-token認証がすべて廃止された、という意味ではありません。

対象agentにAPIキーを設定する場合は、次の対話型コマンドで入力できます。既存キーを使うか再発行するかは、提供元での有効性や取り消し状況を確認して決めます。

openclaw models auth paste-api-key --provider anthropic --agent <agentId>
openclaw models status --agent <agentId>

保存完了と、実行中Gatewayへの適用は同じではありません。コマンドが再起動を求めた場合や自動再読み込みが無効な場合は、openclaw gateway restartで反映し、同じ会話のモデル・アカウント選択を確認します。複数agentを使う環境では、変更コマンドにも対象agentを明示してください。認証変更と適用の仕様

環境変数からキーを読み込む構成では、ターミナルにANTHROPIC_API_KEYが設定されていても、systemdやlaunchdのGatewayサービスに届いているとは限りません。公式案内ではGatewayホストの~/.openclaw/.envなど、サービスが読み込む環境へ設定し、再起動後に確認します。キーを保存したマシン、サービスの実行ユーザー、参照する状態ディレクトリを揃えてください。GatewayホストでのAPIキー設定

Claude CLIを使っている場合

Claude CLIで実行しているなら、Claude Code自身のログインを確認します。手元の別マシンでログインし直しても、サーバー上のGatewayが利用するログインは直りません。Gatewayホストの同じユーザーで次を実行します。

claude --version
claude auth status --text

未ログイン、期限切れ、更新失敗などが確認できた場合は、同じユーザーでログインし直し、Gatewayを再起動します。

claude auth login
openclaw gateway restart

OpenClawはネイティブClaude CLIのログイントークンを読み取り、保存、更新する仕組みではありません。インストール済みのclaudeプロセスが認証を管理します。OAuthトークンを取り出してOpenClawのデータベースにコピーする必要はありません。GatewayがclaudeをPATHから実行できること、CLAUDE_CONFIG_DIRが意図したログインを指していることも確認します。Claude CLIの公式手順

please run /login · API Error: 401 invalid bearer tokenと表示された場合も、どのプロセスから出たメッセージかを確認してください。Claude CLIのログインが失敗しているなら、そのホスト上での再ログインが必要です。別のトークンプロファイルを選んでいる会話では、CLIにログインしただけでは選択済みプロファイルが切り替わらないことがあります。

また、モデル名がanthropic/...であることや「Claude CLI」を選ぶことだけでは、月額プランの枠を使っているとは判断できません。APIキーのアカウントを明示的に選択したClaude CLI実行はAPI課金になります。復旧時に想定外の認証方式へ切り替わらないよう、実行方式と選択アカウントを両方確認してください。実行方式と課金の区別

missing authentication headerなら、キー再発行の前に送信経路を調べる

401 Missing Authentication headerは、受信側が必要な認証ヘッダーを受け取れなかったという手掛かりです。APIキーが失効したと即断せず、失敗した要求の送信先と、認証情報がどう選ばれるかを確認してください。

1. 会話の/model statusで、実際のprovider・モデル・アカウント・実行方式を確認します。
2. 対象agentのmodels statusとmodels auth listで、利用可能な認証情報や選択対象を確認します。
3. カスタム接続なら、models.providers.<id>のbaseUrl、api、モデルIDと、認証プロファイルのproviderが意図した接続先に対応しているか確認します。
4. Gatewayサービスが読む環境、SecretRefの参照先、agentローカルの上書き、auth.orderによる除外を確認します。

エンドポイントの設定と認証情報は役割が違います。baseUrlやAPI形式を変更しても、必要なキーが自動で設定されるわけではありません。逆に、保存済みキーが見えるだけでは、その要求に使われたことも証明できません。提供元設定と認証の区別

独自の中継サーバーを挟んでいる場合は、中継時に認証ヘッダーが落ちていないかも確認対象です。ただし、キーを含む生のヘッダーをログや公開issueに残さず、ヘッダーの有無を秘密値なしで確認してください。

設定と認証情報が揃っているのに同じエラーが続く場合は、バージョン固有の不具合も検討します。OpenRouterでは、issue #51056にOpenClaw 2026.3.13・Linuxでの報告、issue #97934に2026.6.10・macOSでの報告があります。後者の報告者は2026.6.1への戻しで復旧したと述べています。

これは特定環境での過去の報告です。両issueがClosedであることも含め、現在の版が同じ不具合を持つ、またはすべての環境で解決済み、とは断定できません。古い版への一律ダウングレード手順として使わず、自分の版、provider、モデル、更新前後の違いを残して調査してください。

main agentは動くのに、別のagentだけ失敗する場合

現在の保存方式では、agentにローカルプロファイルがなければ共有認証情報を読み取ります。新しいagentごとに同じキーを必ず登録する、という説明は現在の仕様には合いません。

既定の状態ディレクトリでは、保存先は次のように分かれます。

OPENCLAW_STATE_DIRを変更している場合、基点のディレクトリも変わります。共有読み取りは、認証情報を各agentのデータベースへ複製する動作ではありません。共有OAuthプロファイルの更新は共有の保存先に書き戻されます。現在の保存仕様

例えば、共有のanthropic:defaultを更新してmain agentが復旧しても、別のagentが同じIDの古いローカルプロファイルを持っていると、そちらを選んで失敗することがあります。まず対象agentを指定し、利用できるプロファイルと選択順を調べます。以下のanthropicは、実際に失敗しているproviderに置き換えます。

openclaw models status --agent <agentId> --json
openclaw models auth list --provider anthropic --agent <agentId>
openclaw models auth order get --provider anthropic --agent <agentId>

同じIDのローカル設定、選択順から除外された共有プロファイル、会話で固定された別アカウントを区別します。利用可能な認証情報が本当に存在しないなら、Gatewayホストの共有設定またはそのagent向けの認証を設定します。別アカウントで独立運用したいagentには、そのアカウントのログインを用意します。Anthropicのagent別認証エラーへの対処

秘密情報をSQLiteで直接編集したり、正常なagentのOAuthトークンをコピーしたりしないでください。再認証後も古い局所設定が残る、特にアップデート後のケースは次の移行確認へ進みます。

アップデート後の401と古いJSON認証ファイル

更新後に401が出たら、まず版と実行ファイル、Gatewayの状態、doctorの指摘を確認します。以下は確認用で、認証データを書き換える--fixはまだ付けません。

which openclaw
openclaw --version
openclaw update status --json
openclaw gateway status --deep
openclaw doctor

現在、auth-profiles.json、auth-state.json、agent内の旧auth.jsonは移行元であり、実行時の認証保存先ではありません。旧JSONを編集してキーを入れ直す方法は使わないでください。移行が必要な場合はAUTH_PROFILE_MIGRATION_REQUIREDが出て、該当するproviderの認証解決が止まることがあります。JSONからSQLiteへの移行仕様

doctorが移行や古いOAuthの局所設定を指摘した場合、設定と認証状態の復元可能なバックアップを確保し、変更の影響を確認してから実行します。

openclaw doctor --fix
openclaw gateway restart
openclaw models status --agent <agentId>

doctor --fixは認証情報などを変更する修復コマンドです。対応する旧JSONの検証済み値を取り込み、元ファイルを時刻付きで退避します。更新後、再認証してもモデルの401が続くケースでは、古いagent別OAuth設定を除去して現在の共有プロファイルを参照させる処理も公式に案内されています。アップデート後の公式トラブルシューティング

例外は、さらに古い共有ファイルcredentials/oauth.jsonです。このインポーターは廃止されており、現在のdoctorはファイルをそのまま残し、取り込みには2026.9.5を経由する更新が必要だと報告します。このファイルがある場合は、doctorが示す移行経路に従ってください。「古いJSONなら何でも最新版の--fixで読み込める」とは限りません。

古い実行ファイルで新しい設定を操作すると、meta.lastTouchedVersionによる保護が働く場合もあります。そのときはPATHとサービスが使う版を揃えます。ダウングレードが必要なら対応する更新前バックアップと互換性のある版を使い、保護用metadataの削除やSQLiteの手動改変で回避しないでください。版の食い違いとロールバック

修正後は、同じagent・モデル・会話で確認する

復旧確認の基本は、失敗した条件を揃えることです。別のagentや別のモデルが成功しても、元の問題が直ったとは限りません。図のチェック項目を参考に、まず対象agentの状態と会話の/model statusを確認し、短い要求を一度送って結果を見ます。モデルへの実要求には、選択したアカウントの料金や利用枠が適用されます。

静的な確認なら次を使います。

openclaw models status --agent <agentId> --json --check

終了コード0は、設定された経路に認証・実行方式の問題や期限切れ間近の選択済み認証情報が見つからなかった、という意味です。モデル呼び出し成功の証明ではありません。1は不足、失効、互換性の問題、実行方式が利用不能、確認不能など、2はそれらの問題はないものの選択済み認証情報が期限切れ間近の場合です。状態表示の読み方

CLIから実要求を試す必要がある場合は--probeを使えます。ただし現在のCLIは状態ディレクトリの排他的所有を必要とするため、稼働中Gatewayを止める時間を確保してください。<agentId>、<providerId>、<profileId>は確認対象の実際の値に置き換えます。

openclaw gateway stop
openclaw models status --agent <agentId> --probe \
  --probe-provider <providerId> \
  --probe-profile <profileId> \
  --probe-concurrency 1 \
  --probe-max-tokens 8
openclaw gateway start

probeはトークン消費やレート制限を伴う実要求で、--probe-max-tokensもベストエフォートの上限指定です。probeと後処理が完了してからGatewayを起動し直します。タイムアウトや中断で後処理の失敗が報告された場合は、解放完了を確認してから次の操作に進んでください。probeの成功後も、会話固有のモデル選択があるなら元の会話で確認します。probeの動作と制約

No available auth profile (all in cooldown)なら、models status --jsonのauth.unusableProfilesと理由を見ます。レート制限による待機は401による認証拒否と別です。Anthropicのクールダウンはモデル単位の場合があるため、キーを失効させる前に、待機対象と復帰条件を確認してください。クールダウンの公式説明

再認証や移行を終えても同じ401が残る場合は、版、OS、provider、モデル、agent ID、実行方式、発生時刻、秘密値を除いたエラーを揃えて問い合わせます。Gateway接続、認証情報の解決、モデル実行のどこまで成功したかも記録すると、キー交換を繰り返さずに次の調査へ進めます。

よくある質問

OpenClawの401は、APIキーを作り直せば直りますか？

必ずしも直りません。Gatewayの接続トークン、Claude CLIのログイン、モデル提供元のキーは別です。ヘッダー欠落やagentローカルの古い上書きでは、キー再発行より先に送信経路と選択中の認証情報を確認します。

main agentで動くキーを、新しいagentにもコピーする必要がありますか？

現在の仕様では、利用可能な共有プロファイルがあれば新しいagentはそれを読み取れます。同じIDのローカルプロファイルがあると、そちらが優先されます。共有読み取りとコピーは別で、OAuthトークンの手動コピーは避けてください。保存仕様

setup-tokenは、現在も使えますか？

公式の認証ガイドには、現在もsetup-tokenの手順があります。一方、Anthropicの認証エラーへの対処は、トークン失効時の新しい構成にはAPIキーを勧めています。ネイティブClaude CLIのログインとは別の保存済み認証情報なので、どちらを使う会話なのかを確認してください。

models status --checkが成功したのに、401が出るのはなぜですか？

--checkは設定・認証状態の確認で、モデルへの実要求を成功させるテストではないためです。また、設定されたagentの状態と会話固有の上書きが異なる場合もあります。同じ会話の/model statusを確認し、費用や利用枠を理解したうえで短い実要求を試してください。CLIの確認範囲

古いauth-profiles.jsonを編集しても反映されないのはなぜですか？

現在の実行時保存先はSQLiteで、旧JSONは移行元だからです。まずdoctorの指摘を確認し、必要ならバックアップ後にdoctor --fixで移行します。古いcredentials/oauth.jsonには別の移行経路が必要です。移行仕様

この記事の手順は、2026年10月4日に確認した公式資料と、版・環境を限定した公開issueを基にしています。ここでOpenClaw実機の再現試験や有料モデルへの認証probeは実施していません。