Dynamic injection with !`cmd` — and when to refuse it

Your review skill opens with "run git diff HEAD and summarise it." It works most of the time. Sometimes Claude runs a slightly different diff, sometimes it stops to ask permission, and sometimes it decides it already knows what changed and skips the step. Injection removes the choice — the command runs before Claude sees a word of the skill — and charges you a failure mode that takes the whole skill down and a permission path that never asks.

What the syntax does, and when it runs

The !`<command>` syntax runs shell commands before the skill content is sent to Claude. The command output replaces the placeholder, so Claude receives actual data, not the command itself. — Skills

The first skill the documentation teaches is built on it:

---
description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
---

## Current changes

!`git diff HEAD`

## Instructions

Summarize the changes above in two or three bullet points, then list any risks you notice such as missing error handling, hardcoded values, or tests that need updating. If the diff is empty, say there are no uncommitted changes.

Every fact below follows from the order of operations. You invoke the skill; Claude Code runs each command through the Bash tool — the default where bash is available, and the shell every claim here assumes — in your session, now. The rendered text, diff inlined, becomes the message that enters the conversation. Only then does the model read anything, so it never had the option to skip git diff or to run it differently. That is the point, and it is why the failures below are yours to design around rather than the model's to recover from.

Two places the placeholder is not recognised

Both are silent. Nothing errors; the command simply never runs.

The inline form is only recognized when ! appears at the start of a line or immediately after whitespace. — Skills

Row three is a second, separate rule: substitution runs once over the original file, and command output "is not re-scanned for further !`<command>` placeholders, so a command cannot emit a placeholder for a later pass to expand" (Skills). For anything longer than a line, use the fenced form rather than stringing inline placeholders:

## Environment
```!
node --version
git status --short
```

A failed command takes the whole invocation with it

A failed command aborts the entire skill invocation, not just its own placeholder. Claude never sees the skill content for that invocation. The abort shows Shell command failed for pattern "...". — Skills

Not degraded, not "that section came back empty". Nothing. And the error names a pattern rather than your skill, so it reads like an unrelated shell failure.

That carveout list is exact, and its edges are the trap: the tools reference names no matches for pgrep and jq -e, and files that differ for cmp, as cases that count as failures anyway (Tools reference). The documented defusal is one suffix — "append || true to any other command you expect to exit non-zero. A check script that exits 1 when it finds problems is one example" (Skills).

Injected commands never ask

Lesson 1.3 taught the permission prompt as the moment you get a say. Injected commands do not have that moment.

Injected commands never prompt for permission. When a command's permission check returns anything other than allow, Claude Code aborts the invocation. This includes a rule that would normally ask you. — Skills

Exactly two outcomes, then: it runs without telling you, or the skill does not run at all. Pre-approving with allowed-tools (Lesson 7.2) stops an unmatched command aborting, but has a ceiling — "a matching ask or deny rule still aborts the invocation regardless of allowed-tools."

The sharp end of that is someone else's repository. Lesson 7.2's warning is that workspace trust does not gate allowed-tools; put it together with the order of operations above and a skill you did not write can run a command on your machine, pre-approved by its own frontmatter, before the model reads anything and before you approve anything. git clone, claude, /their-skill. Reading a stranger's ! lines is the same habit as reading a diff before accepting it, one step earlier.

Working directory, timeout, stderr, output size

An injected command shares the working directory, timeout and output handling of Claude's own shell commands. Four mechanics follow from that (Skills):

• Working directory. Each command runs in the session shell's current working directory, which moves when Claude runs cd. Paths that must resolve identically every time need ${CLAUDE_SKILL_DIR} or ${CLAUDE_PROJECT_DIR}, which Lesson 7.3 covers.
• Timeout. Each runs under the Bash tool's default 2-minute timeout. One the tool moves to the background still renders, with the injected text naming the background task; one it never auto-backgrounds is killed, and that aborts the invocation like any other failure.
• stderr. Under the default bash shell, stderr is merged into stdout, so every deprecation warning lands in the prompt as context you pay for.
• Output size. Output past the Bash tool's inline ceiling — roughly 30,000 characters by default — "arrives as a file path plus a short preview, not truncated text" (Skills; the ceiling is in Tools reference). A huge diff does not inline itself; it becomes a path Claude has to go and read.

When to refuse it

The docs do not give a rule for when to leave injection out. This table is engineering judgement, and every row traces back to a mechanic above — check each as you read it.

Injection is right when a command is fast, read-only, reliably zero-exit, and needed every single time. git diff, git status --short, node --version — facts you always want, cheap to fetch, boring when they fail.

Turning it off by policy

To disable this behavior for skills and custom commands from user, project, plugin, or additional-directory sources, set "disableSkillShellExecution": true in settings. Each command is replaced with [shell command execution disabled by policy] instead of being run. Bundled and managed skills are not affected. — Skills

{
  "disableSkillShellExecution": true
}

Two properties matter. The replacement is a fixed string, [shell command execution disabled by policy], so what reaches Claude says plainly that a command was skipped rather than leaving a section mysteriously empty — but it does not show you the command, and reading the ! lines is still a job for you and the file. And in managed settings the switch is one-way: "A true in managed settings can't be overridden by false elsewhere" (Settings reference). Set in your own settings, it is a way to open an unfamiliar repository with that repository's skill commands replaced instead of run. One category sits outside the switch in the other direction: Claude Code "never runs these commands on your machine when they appear in skills synced from your claude.ai account, regardless of this setting" (Skills), so everything in this lesson is about skills that live on your disk.