Claude DesktopのMDMポリシーを置く場所 — macOS・Windows・Linux別

Claude Desktopの端末管理ポリシーは、OSごとに置き場所が決まっています。macOSはcom.anthropic.claudefordesktopという設定ドメイン、WindowsはレジストリのSOFTWARE\Policies\Claude、Linuxは/etc/claude-desktop/managed-settings.jsonです。Claude Codeのmanaged settingsとは別の置き場所なので、同じ「ポリシー」でも片方に書いただけでは、もう片方には届きません。

OSごとの置き場所を先に一覧する

ポリシーでできることは、Claude Code機能の有効・無効、macOSとWindowsでの自動更新の制御、独自のデプロイURLの設定などです。キー名・型・既定値の一覧はClaude DesktopのSSO必須化とデバイス管理ポリシーの設定のキー表にあります。この記事は、その表のキーを「どこに置くか」に絞ります。

macOS: 構成プロファイルを配るドメイン

macOSのDesktopは、com.anthropic.claudefordesktopというドメインから設定を読みます。配る手段は、Jamf Pro・Kandji・Intuneの構成プロファイルです。ProfileCreatorやiMazing Profile Editorで作ったプロファイルも使えます。

ここで押さえる点は、ドメイン名がclaudefordesktopである点です。Claude Code側のドメインはcom.anthropic.claudecodeで、名前が似ていて綴りも1語ずつしか違いません。MDMのプロファイルに入れるドメイン名を取り違えると、Desktopは別のドメインを見に行くことになり、意図した設定が読まれません。配る前に綴りを見直す価値があります。

値の型には決まりがあります。forceLoginOrgUUIDに複数の組織を許すときは、JSON配列そのものではなく、JSON文字列を<string>に入れます。

<key>forceLoginOrgUUID</key>
<string>["<uuid-1>","<uuid-2>"]</string>

PKGでの配布からプロファイルの作成までの流れは、Claude DesktopをmacOSで一括導入する手順(PKG)で扱っています。

Windows: HKLMとHKCUのどちらに書くか

Windowsでは、グループポリシーまたはIntuneのポリシーで、レジストリのSOFTWARE\Policies\Claudeに値を置きます。マシン全体に効くHKLMと、ユーザー単位のHKCUのどちらにも置けます。両方に同じ設定があるときは、マシンレベルが優先されます。

管理者権限のPowerShellで直接書き込む場合は、次の形になります。

New-Item -Path "HKLM:\SOFTWARE\Policies\Claude" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" `
  -Name "isDesktopExtensionEnabled" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" `
  -Name "autoUpdaterEnforcementHours" -Value 72 -Type DWord

値の型に注意が要るキーが2つあります。

• forceLoginOrgUUIDに複数のUUIDを渡すときは、JSONテキストをREG_SZの文字列として保存します。REG_MULTI_SZは使いません
• disableWslSessionsは、REG_SZのfalseかREG_DWORDの0で設定します

HKCUは何でも置ける場所ではありません。disableWslSessionsに限っては、HKCUに値を置いてもWSLセッションは有効になりません。HKLMへの書き込みには管理者権限が要ります。WSLの手順はdisableWslSessionsでClaude Code DesktopのWSLを組織展開するに詳しく書きました。

Linux: root所有のJSONファイル

LinuxのDesktopにはplistもレジストリもないので、ファイルで渡します。置き場所は/etc/claude-desktop/managed-settings.jsonで、中身はポリシーのキーを並べたJSONオブジェクトです。

このファイルには、他のOSにない条件が1つあります。Desktopは、root以外がそのファイルかその置き場所のフォルダーに書き込める状態だと、ファイルごと拒否します。一般ユーザーが書き換えられるポリシーは、ポリシーとして成立しないからです。

作るときは、ディレクトリとファイルの両方をroot所有にして、他者に書き込み権限を与えません。

sudo install -d -m 755 -o root -g root /etc/claude-desktop
sudo tee /etc/claude-desktop/managed-settings.json >/dev/null <<'EOF'
{
  "isLocalDevMcpEnabled": false,
  "effortLevel": "high"
}
EOF
sudo chown root:root /etc/claude-desktop/managed-settings.json
sudo chmod 644 /etc/claude-desktop/managed-settings.json
ls -ld /etc/claude-desktop /etc/claude-desktop/managed-settings.json

上のJSONはファイルの形を示すための例です。2つのキーを選んだ理由は、キー表にBoolean型と文字列型の例として載っているからで、Linux版でこの2つが効くという意味ではありません。Linuxで有効なキーの範囲は、公式の説明にキー単位の記載がありません。自動更新の制御については、公式がmacOSとWindowsを対象として書いています。Linuxの導入手順はClaude Desktop Linux版(beta)のダウンロードとインストール手順にあります。

ls -ldの出力で確認するのは、所有者がrootで、グループと他者に書き込み権限(w)がないことです。drwxrwxrwxのようなディレクトリや、root以外が所有するファイルは拒否の対象になります。構成管理ツールでファイルを配る場合は、配布後に所有者と権限を上のコマンドと同じ状態に揃えます。

Claude Codeのmanaged settingsとは何が違うのか

名前が似ているために、最も取り違えが多いのがここです。Claude Codeのmanaged settingsは、Desktopのポリシーとはドメイン、レジストリキー、ディレクトリのすべてが別になっています。

Linuxの2つは、ファイル名が同じで、ディレクトリ名のclaude-desktopとclaude-codeだけが違います。ls /etc | grep claudeで両方が見えたとき、ディレクトリを取り違えて作業しやすい並びです。

役割も違います。Desktopのポリシーは、アプリがどう動くか(更新、ログイン先、拡張機能、Coworkの有効化など)を決めます。Claude Codeのmanaged settingsは、セッションの中で何ができるか(権限ルール、フック、モデルの選択肢など)を決めます。

同じ製品の設定でも、置く先が分かれるキーがある

Desktop上のCode tabに関わるキーでも、どちらに置くかはキーごとに決まっています。

WSLを例にすると、disableWslSessionsでセッションを開けるようにしても、開いたセッションにmanaged settingsを効かせるには、Claude Code側でwslInheritsWindowsSettings: trueも要ります。2つのキーは役割が補い合う関係で、片方を置いたからもう片方が不要になるわけではありません。

置いたのに効かないときの切り分け

まず疑うのは置き場所の取り違えです。次の順に確かめます。

1. ドメイン・キー・ディレクトリの綴り: macOSはclaudefordesktop、WindowsはPolicies\Claude(ClaudeCodeではない)、Linuxはclaude-desktopか
2. 値の型: Booleanの項目に文字列を入れていないか。forceLoginOrgUUIDの複数指定をREG_MULTI_SZにしていないか
3. Linuxの権限: ファイルとディレクトリの両方がroot所有で、root以外に書き込み権限がないか
4. 読み込みのタイミング: forceLoginOrgUUIDは起動時に読まれます。変更後はDesktopを終了して開き直します
5. WSLの場合: ポリシーの拒否理由はログに出ます。WindowsでHelp > Troubleshooting > Show Logs in File Explorerを開き、main.logの[wslPolicyGate] denying WSL sessionを探します

アプリが実際に読んだ値を確かめるには、Help > Troubleshooting > Generate Diagnostic Reportを使います。配布した値とレポートの値が食い違っていれば、置き場所か型を見直す手がかりになります。

拡張機能の許可リストとの関係にも注意が要ります。端末レベルのポリシーは、アプリ内の許可リストより優先されます。許可リストを使う場合は、isDesktopExtensionEnabledとisDesktopExtensionDirectoryEnabledをfalseにしないでください。許可リストの有効化はClaude Desktop拡張機能の許可リストを有効にする手順で扱っています。

どの経路でどのファイルを触るか

担当する機能ごとに、どの置き場所を触るかをまとめます。

• アプリの更新・ログイン先・拡張機能・Coworkの有効化: Desktopのポリシー(この記事の3つの置き場所)
• 権限ルール・フック・モデル選択: Claude Codeのmanaged settings(OSごとのファイルまたはMDM)
• 組織全体のDesktopアクセスやクラウドセッションのオン・オフ: 管理コンソール。端末には何も置きません

Linuxに限ると、Desktopのポリシーとmanaged settingsを両方配る端末では、/etcの下に2つのディレクトリができます。それぞれを別のチームが管理しているなら、置き場所を台帳に分けて書いておくと、取り違えを防げます。管理コンソール・managed settings・MDMの使い分けは、SSOとデバイス管理ポリシーの記事の冒頭にある表が出発点になります。Claude Code側の置き場所と優先順位はClaude Codeのmanaged settings解説を参照してください。