disableSkillShellExecutionでskillのインラインシェル実行を止める

disableSkillShellExecutionは、skillとカスタムコマンドに書かれたインラインシェルの実行を止める設定です。trueにすると、!`...` と```!ブロックはコマンドとして走らず、[shell command execution disabled by policy]という文字列に置き換わります。v2.1.91で追加されました。

skillの本文に書いたコマンドは、Claudeに渡る前にユーザーの端末で実行されます。第三者が作ったskillを取り込む環境では、この実行を組織として止めたい場面があります。この設定はそのための1行です。

disableSkillShellExecutionは何を止める設定か

skillには、本文を送る前にシェルコマンドを実行して出力を差し込む記法があります。たとえばPRの差分を取る!`gh pr diff` のような行です。コマンドの出力が本文に入るので、Claudeは命令ではなく実データを受け取ります。

この設定をtrueにすると、その実行自体をやめます。コマンドは走らず、代わりに置換文字列が本文に入ります。値は次の2つです。

未設定のときは実行されます。既定で止まっているわけではない点に注意が必要です。スコープは設定ファイルのどれでも置けるAny fileで、user・project・local・managedのどこにも書けます。

{
  "disableSkillShellExecution": true
}

止まる記法と、そもそも動かない記法

止まるのは次の2つの記法です。

• 1行で書くインライン形式: !`<command>`
• 複数行を囲むフェンスドブロック: ```! で開くブロック

インライン形式は、!が行頭か空白の直後にあるときだけコマンドとして認識されます。KEY=!`cmd` のように他の文字に続くと、そもそも文字どおりのテキストとして残ります。この場合は設定にかかわらず実行されません。

置換は元ファイルに対して1回だけ走ります。コマンド出力は平文で入り、出力の中の!`...` が再展開されることはありません。止めた状態でも、この性質は変わりません。

対象になるskillとならないskill

置換の対象は、user・project・plugin・追加ディレクトリのどれかから来たskillとカスタムコマンドです。プラグインのコマンドも含まれます。変更履歴にも、skills・custom slash commands・plugin commandsの3つが並んでいます。

対象外は2種類です。

組織が自分で配るskillはコマンドを実行でき、利用者が持ち込んだskillのコマンドだけが止まります。組織が中身を管理しているskillと、そうでないskillで扱いを分ける設計です。

claude.aiのアカウントから同期したskillは別枠です。同期されたskillの本文にあるコマンドは、この設定の値に関係なく、手元のマシンで実行されません。この制限にはv2.1.228以降が必要です。

同期skillの本文がどう届くかは、セッションの種類で変わります。

手元のマシンのその他のセッションでは、@参照のファイル添付と、${CLAUDE_PROJECT_DIR}・${CLAUDE_SESSION_ID}の置換も行われません。これらもリテラルのままClaudeに届きます。Coworkを使う組織では、同期skillの!行が設定に関係なく置換文字列になる点を前提にskillを作る必要があります。

managedでtrueにすると、他の設定ファイルで戻せない

この設定はAny fileに置けますが、効果が大きいのはmanaged settingsです。trueをmanagedに書くと、userやprojectのfalseでは上書きできません。skillの説明にも、managed settingsではユーザーが上書きできないので最も有用だと書かれています。

一方で、userやprojectにtrueを書くのは、本人の判断で自分の環境を絞る使い方です。プロジェクトを開く人ごとに挙動が変わるので、組織の統制にはなりません。

配布の置き場所や優先順位の全体像は、managed settingsによる組織管理の記事にまとめています。

設定してから確かめる手順

設定が効いているかは、コマンドを含む小さなskillで確かめられます。

mkdir -p .claude/skills/shell-check
cat > .claude/skills/shell-check/SKILL.md <<'EOF'
---
name: shell-check
description: インラインシェルの実行可否を確かめる
---
 
現在時刻: !`date`
EOF

この状態でClaude Codeを起動し、/shell-checkを実行します。設定がfalseか未設定なら、!`date` の位置に日時が入ります。trueなら、同じ位置に[shell command execution disabled by policy]が入ります。置換は設定リファレンスに記載された挙動で、日時のコマンドは走りません。Claudeに「skillの本文に何が入っていたか」を尋ねると、日時が入っているか置換文字列が入っているかで、設定が効いているかを見分けられます。

managedで配る前に、手元のuser設定で試すのが手軽です。動作を見てからmanagedに移せば、利用者に届く挙動を事前に把握できます。

allowManagedPermissionRulesOnlyと組み合わせると何が変わるか

managedで統制する組織には、もう1つ関係するキーがあります。allowManagedPermissionRulesOnlyをtrueにすると、managed settingsが権限規則の唯一の出どころになります。user・project・localのallow・ask・denyは無視され、--allowedToolsも効かなくなります。

skillへの影響は、allowed-toolsの扱いに出ます。v2.1.282以降では、リポジトリの.claude/、~/.claude/skills/と~/.claude/commands/(claude.aiから同期したskillを含む)、--add-dirのディレクトリ、プラグインから来たskillのallowed-toolsが無視されます。managedで配るskillと同梱skillは、allowed-toolsが残ります。disallowed-toolsは引き続き効きます。

この2つは役割が違います。

disableSkillShellExecutionがfalseのままでも、allowManagedPermissionRulesOnlyをtrueにしておけば、持ち込みskillの注入コマンドはmanagedの規則に合うものしか通りません。規則に合わないコマンドは、自動モード以外では呼び出しごと中止されます。どのskillでallowed-toolsが無視されたかは、/statusで一覧できます。

複数の管理元がある環境では、どれか1つでもこのキーをtrueにすると、埋め込み元のホストが渡す親設定のallow規則とadditionalDirectoriesは、優先度の高い管理元が未設定でも読み込み時に捨てられます。

allowManagedPermissionRulesOnlyにはCowork側の副作用もあります。Coworkはセッションの起動時に、接続した作業フォルダーへのアクセスをallow規則として渡します。このキーがtrueだと、managedの規則に無いallow規則は捨てられ、そのフォルダーへの書き込みは事前許可を失います。編集前に確認を出すCoworkセッションでは確認の画面を出せないため、Claudeは書き込みを「保護された場所か、接続したフォルダーの外」として失敗扱いにします。Coworkの書き込みを残したいときは、そのフォルダーへのallow規則をmanagedの側に足します。MDMで配っている環境では、設定ファイルではなくMDMのポリシーに足します。allowの対象は、各ユーザーのホームにあるCoworkProjectsのようなフォルダー単位で書けるので、allowManagedPermissionRulesOnlyはtrueのまま、ユーザーが接続するフォルダーだけを通せます。

コマンドを動かしたうえで統制したいなら権限規則、そもそも動かしたくないならdisableSkillShellExecution、という使い分けです。両方をtrueにすれば、持ち込みskillは実行も事前許可もできません。

止める前に、注入コマンドが何をしているかを知る

この設定が止める実行は、通常は次のように動いています。止めた後に何が失われるかを測る材料になります。

• 実行先: frontmatterのshellキーと環境で決まり、BashツールかPowerShellツールが走らせる。shell: bashでbashが無い環境(Git Bashの無いWindowsなど)では、呼び出しがコマンド実行前に失敗する
• 作業ディレクトリ: セッションのシェルのカレントディレクトリ。Claudeがcdすると動くので、固定したいパスには${CLAUDE_SKILL_DIR}か${CLAUDE_PROJECT_DIR}を使う
• stderr: 既定のbashではstdoutに合流し、注入されるテキストに混ざる
• タイムアウト: Bashツールの既定の2分
• 失敗時: 1つのコマンドが失敗すると、そのプレースホルダだけでなくskillの呼び出し全体が中止され、Claudeにはskillの内容が渡らない

PowerShellを使うskillでは、frontmatterのshell: powershellを指定します。PowerShellツールが有効なときは、注入コマンドがそちらで走ります。有効になる条件は環境ごとに違い、Git Bashの無いWindowsでは既定で有効です。Git Bashがあるときは、claude.aiとConsoleのアカウントで既定で有効になります。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryのセッション、およびmacOS・Linux・WSLでは、CLAUDE_CODE_USE_POWERSHELL_TOOL=1が要ります。0にするとツールを止められます。

失敗の扱いにも、シェルごとの差があります。bashでは終了コード1を正常な結果として扱うコマンドがあり、grepはその例です。PowerShellでは対象の集合が別で、grepとgit diffは含まれますが、findとdiffは含まれません。bashで期待を外れた終了コードを返しうるコマンドには、|| trueを付けて失敗を避けます。

最後の点は見落とされがちです。コマンドが落ちるたびに呼び出しが中止される仕組みが、trueのときは働きません。コマンドを実行しない以上、失敗による中止も起きず、skillは置換文字列入りの本文でそのまま読み込まれます。

権限の面でも違いがあります。注入コマンドは、skillを描画する間は確認を出さず、権限規則を先に照合します。拒否規則に当たれば中止され、askに当たるものも自動モード以外では中止されます。allowed-toolsで事前に許可すれば通りますが、拒否規則とask規則はallowed-toolsより優先されます。止めてしまえば、この照合も要らなくなります。

止めたときに壊れるskillの見分け方

コマンド出力を前提にしたskillは、止めると中身が空になります。冒頭の!`gh pr diff` のように、実行結果を本文に埋め込む型がその典型です。置換文字列しか入らないので、Claudeは差分を持たないまま指示だけを受け取ります。

導入前に、次の点を棚卸ししておくと混乱が減ります。

1. 組織で使っているskillのうち、!`...` か```!を含むものを洗い出す
2. 出力を差し込む型は、Claudeに自分でコマンドを実行させる書き方へ直す
3. 組織が管理するskillは対象外なので、必要なものはEnterprise skillとして配る

2番目の「自分で実行させる」書き方なら、コマンドはClaudeのシェル呼び出しになり、通常の権限チェックを通ります。設定をfalseにしたままでも、skillの注入コマンドには権限規則が働きます。拒否規則に当たると呼び出しが止まります。

隣接する設定との線引き

skillやコマンドを絞る手段は複数あり、止める範囲が違います。

この設定は「skillは使わせるが、本文からのコマンド実行は許さない」位置にいます。skill全体を消す前の中間の選択肢です。

skillとコマンドを丸ごと無効にしたい場合は、--disable-slash-commandsの解説に手順があります。skill側の書き方や呼び出し制御はClaude Code Skills完全ガイドにあります。user・project由来を締め出す方式はstrictPluginOnlyCustomizationの記事が詳しく、どちらも併用できます。

この設定が追加されたバージョン

設定はv2.1.91(2026年4月2日)で追加されました。同じ版には、MCPツール結果の永続化を上書きする指定なども入っています。版全体の内容はv2.1.91のリリースノートで確認できます。

古いバージョンのClaude Codeが残る環境では、キーが認識されず、コマンドが実行されたままになる可能性があります。managedで配る前に、利用者側のバージョンを揃えておくのが確実です。

まとめ

disableSkillShellExecutionは、skill本文のコマンド実行だけを置換文字列に変える1つのキーです。managedにtrueを書けば、userやprojectのfalseで戻されません。

効き目を決めるのは、どのskillを対象外として残すかです。組織が配るskillにコマンド出力が必要なら、Enterprise skillとして置けば動きます。持ち込みのskillで出力を差し込む型を使っているチームは、導入前に書き方を直す作業が要ります。