Remote managed settings failed to loadの原因 — Claude Code
Claude Codeの起動時に出るRemote managed settings failed to loadは、括弧内の原因で対処が変わります。承認拒否や管理ポリシーの読み取り失敗で終了するメッセージも扱います。
Remote managed settings failed to load (<原因>)は、組織のサーバー管理設定を取りに行ったClaude Codeが、取得できなかったか、取得した内容を適用できなかったときに対話セッションで出す警告です。エラーで止まるわけではなく、セッションは続きます。見るべきなのは括弧の中の原因と、行の後半にある「どのポリシーで動いているか」の2点です。
同じ系統で、起動そのものが終わってしまうメッセージが2つあります。Managed settings were not approvedとUnable to read managed policy settingsです。この記事では3つをまとめて、読み分け方と次の一手を扱います。
この警告が出る条件と、警告で済むもの
警告の対象になるのは、サーバー管理設定(server-managed settings)の配信対象になっているセッションです。配信にはTeamまたはEnterpriseプラン、Owner権限での設定、api.anthropic.comへの到達性が前提になります。取得に失敗しても、既定ではセッションは止まりません。
- 以前の取得で保存したキャッシュがあれば、そのポリシーで続行する
- キャッシュが無ければ、サーバー管理設定なしで続行する(MDMや
managed-settings.jsonのエンドポイント管理設定は別途適用される)
つまりこの警告は「管理ポリシーが最新でない、または欠けた状態で動いている」という通知です。ポリシーが欠けた状態を許さない組織は、forceRemoteSettingsRefreshで警告を終了に変えています。その仕組みはforceRemoteSettingsRefreshの解説にあります。
括弧内の原因を読み分ける
括弧の中身は、何が失敗したかを指します。例として挙がっているのは次の3つと、検証失敗の1つです。
| 括弧内の原因 | 起きていること | 次の一手 |
|---|---|---|
network error | 起きていること取得リクエストが相手に届かなかった | 次の一手この端末からapi.anthropic.comに到達できるか、プロキシ設定を確かめる |
request timed out | 起きていること応答が返る前にタイムアウトした | 次の一手同じく疎通と経路の遅延を確かめる |
authentication rejected (401) | 起きていること認証情報が受け付けられなかった | 次の一手/statusでサインイン状態を確認し、必要なら再認証する |
no setting in the server response could be applied as written | 起きていることサーバーは応答したが、返った設定がどれも検証を通らなかった | 次の一手利用者側では直せない。管理者にサーバー側の設定修正を依頼する |
最後の原因は、v2.1.282より前はserver returned invalid settingsという文言でした。古いバージョンの画面や過去のスクリーンショットと見比べるときは、同じ事象として読みます。
設定の一部だけが不正なときは別扱い
配信された設定の一部だけがスキーマ検証に失敗した場合、Claude Codeは検証エラーを表示したうえで、残りの有効な設定を適用します(v2.1.169以降)。この警告になるのは、ペイロードの全項目が検証に失敗し、より厳しい値へのフォールバックも起きず、保持期間系の2キー以外のキーを含むときです。この場合は何も適用せず、キャッシュも更新しません。
管理者側の設定ミスで全社に出る可能性があるのは、この最後の原因だけです。ネットワークや認証の原因は、端末ごと・時間帯ごとに出方が変わります。
行の後半が示す「いま効いているポリシー」
括弧のあとに、セッションが何のポリシーで動いているかが続きます。
警告の後半で変わるセッションの状態
using cached policy
以前の取得に成功した設定で動いています。ただし、サーバーの確認が取れるまで保留される環境変数(プロキシ・証明書・エンドポイント・認証情報に関わるもの)は適用されません。
no remote policy applied
サーバー管理設定なしで動いています。初回起動や/logoutの直後に取得が失敗すると、この状態になります。
using cached policyでも、保留される変数の影響を受ける点は見落としやすいところです。社内プロキシの値をサーバー管理設定のenvで配っている組織では、キャッシュ起動の段階でその値が効いていません。プロキシをエンドポイント管理設定、シェル環境、ユーザー設定のいずれかに置けば、取得そのものにも届きます。初回起動にはキャッシュが無いため、この3つのいずれかが必須になります。
手元で原因を絞る手順
警告の文面だけで足りないときは、診断コマンドで同じ行を確認します。
claude doctorManaged settings (remote)の行がフェッチ結果です(v2.1.248以降)。表示は次の4通りです。
- 配信された設定が読み込まれた
- 組織にサーバー管理設定が設定されていない
- 取得に失敗した(原因と、キャッシュが適用されているかを含む)
- 取得をスキップした(理由つき)
実行中のセッションでは、取得失敗の後や一部のスキップ原因のときに/statusにも同じ行が出ます。さらに掘るなら、デバッグログを書き出してRemote settingsで検索します。
claude --debug-file ./claude-debug.log
grep "Remote settings" ./claude-debug.logv2.1.248より前は、取得失敗はデバッグログにしか出ませんでした。古いバージョンでは警告が出ないまま管理設定が効いていない、という状況があり得ます。
警告が出たときの切り分け
- Q括弧の中は network error か request timed out か答えがいいえ答えがはい
端末から
api.anthropic.comへの経路を確かめます。プロキシを使う環境では、シェル環境かユーザー設定にプロキシを置きます。 - Q括弧の中は authentication rejected (401) か答えがいいえ答えがはい
/statusでサインイン先を確認します。切れているなら再ログインします。 - Q括弧の中は no setting in the server response could be applied as written か答えがいいえ
端末側に原因はありません。管理者に、サーバー側の設定の修正を依頼します。
警告が出ないのに管理設定が効かないとき
取得が失敗するのではなく、取得自体が行われない構成があります。警告は出ず、claude doctorのManaged settings (remote)行に「スキップ」と理由が出ます。
apiKeyHelperスクリプトが返すキーや、Workload Identity Federationの認証情報では、取得が走りません- シェルで
CLAUDE_CODE_USE_*系のプロバイダー変数や、既定値以外のANTHROPIC_BASE_URLをエクスポートしていると、そのセッションは取得をスキップします - ConsoleのAPIキーは、作成したConsole組織に属します。claude.aiのTeamまたはEnterprise組織の設定は、そのキーのセッションには届きません
- Claude DesktopアプリのCoworkセッションは、Team・Enterpriseでサインインしていても、管理コンソールからは取得しません
シェルのエクスポートは、サーバー管理設定のenvでは消せません。そのenv自体が、エクスポートで止められた取得によって届くためです。シェルから変数を外すか、ユーザー設定のenvで空文字にします。
Managed settings were not approvedで終了する
Managed settings were not approved; exiting without applying them.こちらは警告ではなく、終了です。配信された設定に承認が必要な項目が含まれていて、セキュリティ承認ダイアログを拒否すると、Claude Codeは設定を適用せずに終了します。
承認が必要になるのは、apiKeyHelper・statusLine・otelHeadersHelperのようにシェルコマンドを実行する設定、サンドボックスの実行ファイルやネットワーク・分離に関わる設定、プロキシやベースURLなど一部の環境変数、フック定義です。管理者が配るclaudeMdは承認の対象外です(v2.1.260以降)。
- 拒否した記録は残らないため、次に起動すれば同じダイアログがもう一度出ます
- ダイアログに載った項目に心当たりがなければ、承認する前に管理者へ確認します
承認の記録の持ち方は認証情報で変わります。
| サインイン方法 | 承認の単位 | 再表示される場面 |
|---|---|---|
| claude.aiのログイン | 承認の単位組織ごとに1件(直近に承認したアカウントが優先) | 再表示される場面同じ組織に別アカウントでサインインしたとき |
| Claude apps gateway | 承認の単位ゲートウェイごとに1件 | 再表示される場面承認対象の設定が変わったとき、別のゲートウェイにサインインしたとき |
| APIキーなどその他 | 承認の単位キャッシュと同じ設定ディレクトリに1件 | 再表示される場面承認対象の設定が変わったとき、/logoutでキャッシュが消えたとき |
claude -pやAgent SDK、VS Codeのチャットパネルのような対話できない実行では、ダイアログを出せません。承認が必要な設定は、その回だけ適用され、承認済みとしては記録されません。次に対話セッションを開くと、改めてダイアログが出ます。
Unable to read managed policy settingsで起動しない
Unable to read managed policy settings.
This machine may require organization login enforcement, but the policy file failed to load.
Contact your administrator.
Detail: <source>: <reason>組織が管理設定を配布していて、その配布元のファイルなどが存在するのに読めなかった場合に出ます。I/Oエラーのような理由が対象で、ほかに有効な管理ソースがなければ、Claude Codeは起動時に終了します。ポリシーが組織ログインの強制を含んでいる可能性があるため、読めないままでは動かさない設計です。
同じ状態では、サインイン処理、すでに動いているセッションからのAPIリクエスト、claude gatewayサーバーも拒否されます。そのときの1行目は、allowedProvidersに触れる変形になります。
読めない理由によって挙動が分かれます。
- OSが読み取りを拒否した場合(rootだけが読めるファイルなど)は、この終了にはなりません。そのソースのポリシーなしで起動します
- パースできないソースの場合は、ソース名を示す別のメッセージで終了します
端末の管理者なら、Detail:行が示す原因を直して配布元を読める状態にするか、そのソースを取り除きます。管理者でないなら、メッセージ全体を管理者に送ります。利用者側の設定ファイルが原因にも解決にもならないエラーです。
管理者が先に決めておくこと
利用者から問い合わせが来る前に、管理者側で確認できる点があります。
- 新しい設定を配る前に、テスト機で
claude doctorを実行し、Managed settings (remote)行で結果を確かめる - 承認が必要な項目(フック、シェルコマンド、プロキシ変数など)を足すと、ダイアログの拒否による終了と、承認待ちの再表示が発生しうる
- 警告で済ませるか、終了させるかは
forceRemoteSettingsRefreshで決まる。有効にした組織では、取得失敗時に警告ではなく終了になる - 管理設定の解決結果をログに残す方法は、OTEL_LOG_MANAGED_SETTINGSの解説にある
- 組織管理の全体像はClaude Code組織管理ガイドにまとまっている
まとめ
Remote managed settings failed to loadは、括弧内の原因がnetwork error・request timed out・authentication rejected (401)なら端末側の疎通と認証を、no setting in the server response could be applied as writtenなら管理者のサーバー設定を見ます。起動が止まる2つのメッセージは、承認ダイアログの拒否と、ポリシーファイルの読み取り失敗が原因です。前者は再起動して承認すれば進み、後者は管理者が配布元を直すまで進みません。