Argument substitution corrupts literal $N text (prices, awk fields) in command/skill file content — including fenced code blocks; no opt-out

Independent re-discovery of this on macOS, via the programmatic Skill-tool path — confirming it is loader-level and platform-independent, as you say. Adding one angle not covered above, because it changes the severity argument:

The corruption can destroy the instruction that is about the token.

In our case the affected line was a safety rule in an agent skill: prose instructing that token-denominated usage must be reported as uncosted and never as $0, because a zero-dollar figure would falsely assert a measured zero spend. Invoked with a ticket id as the argument, the delivered text became "...never as FOO-123, which would falsely claim a measured zero-dollar spend."

The rule was therefore silently disarmed at exactly the moment an agent was reading it — and the class of prose most likely to contain a literal $0 is precisely the prose warning about $0. Anti-fabrication and cost-reporting guidance is disproportionately exposed, and a corrupted instruction reads as merely nonsensical rather than as tampering, so a model is unlikely to flag it.

Two smaller notes:

• The on-disk file and the plugin-cache copy are byte-identical, so the usual "is my cache stale?" debugging path leads nowhere. There is no signal at all short of diffing delivered text against the file.
• Mitigation other skill authors can copy today: a CI check that rejects a dollar-sign followed by a digit anywhere in skills/*/SKILL.md, plus rewording prose to avoid the literal ("a zero-dollar figure"). We chose rewording over the documented backslash escape because a corpus-wide scan is mechanically enforceable against reintroduction, whereas an escape has to be remembered by every future author.

Strong +1 on the opt-out — for agent skills, body text being data rather than a template is the safer default.

Disclosure: drafted with Claude Code's help; I reproduced the behaviour myself on the version stated, checked the claims, and will answer follow-ups.

Confirming this on Claude Code 2.1.220 (Debian 13 in a devcontainer, Node 24.18.1), which is later than the builds named above, and adding one consequence class I do not think is covered yet.

A probe skill invoked as /subst-probe alpha beta:

in the file                     received
---------------------------     ---------------------------
$0 and $1                       alpha and beta
\$0 and \$1                     $0 and $1
$7  (no such argument)          $7
$ARGUMENTS                      alpha beta

# inside a fenced block
awk '!seen[$0]++'      ->   awk '!seen[alpha]++'
awk '!seen[\$0]++'     ->   awk '!seen[$0]++'
"$7"                   ->   "$7"

So: fence scope confirmed again, escape confirmed working inside fences as well as prose, unsupplied indices left alone — all as you describe.

The instance that led me here is worth adding for two reasons beyond "it happened to us too".

It produced confident misinformation, not just a broken script. The corrupted line was a deduplication step, awk '!seen[$0]++', in a skill that inventories the pull requests a session opened. Invoked as /close-out thanks, it became awk '!seen[thanks]++' — still valid awk, but keying every line on one constant, so it emits only the first record. The assistant read that output, concluded the skill itself contained a bug, and reported that to the user as a defect in their file. The file was correct. Because the corruption exists only in the model's context and never on disk, there was nothing to diff and no way to see it from the file — the user worked out what had happened only because they remembered they had typed an argument.

The corrupted value drove a destructive step. That inventory decides which git worktrees get torn down at the end of a session. A list silently truncated to one entry means the rest are left standing — benign in that direction, but the same shape with the substitution landing elsewhere would remove the wrong thing. Any command that computes a list and then acts on it has this exposure.

Both are consequences of the property already in your summary — that the corruption is invisible to diffs and code review — but they show it reaching past "the embedded script misbehaves" into "the agent reports a falsehood about the user's code" and "the agent acts on a truncated list". That seems worth weighing when ranking request 1 (per-file opt-out) against request 2 (fence exemption). For what it is worth, the fence exemption would have covered our case entirely, and the escape — which does work — did not help, because nobody knew it was needed.

Also a small note on the failure's shape, which is why it survived: an unsupplied index is left literal, so a skill containing $0 is correct every time it is invoked without arguments and corrupt only when someone passes one. Ours had been right for weeks.

Independent confirmation of this report, from a controlled experiment run without knowledge of this issue — so the agreement is genuinely independent rather than a re-reading of it. We drafted a standalone report before searching the tracker, found this, and are commenting rather than filing a duplicate. #78759 is the better report; everything below is additive.

Different platform and a different reason to believe it's loader-level. This issue notes Windows 11 with platform-independence as a hypothesis. Ours was measured on WSL2 / Ubuntu 24.04.3, kernel 6.6.87.2, Node v24.15.0, Claude Code 2.1.220 — four live Skill-tool invocations across two separate skill trees (a local repo-symlinked tree and an installed plugin tree), with the on-disk file asserted byte-identical by grep -nF before and after each probe. Same behavior. That makes the platform-independence claim measured on two platforms rather than inferred from one.

Confirming your specifics: $0 is the first argument (measured at three index points), fences do not protect, markdown tables and plain prose are rewritten, and $2.50/M became TWOTOK.50/M mid-token. We did not independently measure your maximal-munch finding ($200K → index 200) — that's new to us and worth keeping front and center.

---

The severity case is stronger than "plausible-looking wrong numbers"

Your awk example (l=$0 → l=857) breaks the command, which at least surfaces. We have a measured case that does not surface at all.

One of our skills computes a progress fraction with a two-pass awk program whose body uses $0, $1 and $2. Run against the skill's own frozen positive control, which must yield 23/23, the delivered form yields 0 0, exit 0. Downstream the skill then prints no denominator — a message it explicitly sanctions for a different and legitimate reason (a worklist that genuinely has no checkboxes).

So, simultaneously:

• exit 0, no error, no warning;
• the output is a value the tool already treats as normal;
• nothing in the output distinguishes "corrupted" from "valid";
• and the result is written into an append-only journal, so the wrong value is durable.

Mechanism, derived from the program text and consistent with the measured output: pass one gates all counting on a flag set by testing $0 against a section heading. With $0 replaced by a bareword, that bareword is an uninitialized awk variable — the empty string — which never matches, so no counting rule ever fires and the totals print 0 0. Pass two exists as a deliberate fallback and reads a pointer using $1 and $2; those were substituted too, so the fallback is skipped as well. Every branch of a deliberately redundant computation is disabled by the same rewrite, and the redundancy that was supposed to make it trustworthy is what makes the failure total.

Why "unsupplied indexed tokens stay literal" is the severity multiplier, not a footnote

Your report states this as documented behavior, which it is. We'd argue it deserves promoting to a headline, because it is what removes the fail-loud path. We measured it across 8 out-of-range references.

Emptying an out-of-range $N would usually produce an awk/perl syntax error — loud, immediate, attributable. Leaving the literal in place means the corrupted program frequently stays syntactically valid and exits 0. Every affected site therefore fails open. There is no configuration in which this defect announces itself.

The wrong answer is chosen by whatever the user happened to type

Derived, not measured, and it follows from the substituted value being the user's own args text. A filter like awk '$1 > 0 && $1 < 1900':

• with a non-numeric token becomes constant-false — silently drops every record;
• with a numeric token such as 5 becomes awk '5 > 0 && 5 < 1900', constant-true — silently passes every record, including the ones the filter existed to reject.

Same defect, opposite wrong answer, selected by unrelated user input. This is why we don't think an author-side escaping discipline is a durable mitigation: the author cannot enumerate the failure modes, because they depend on the caller.

A free triage signal (observed correlation, not a traced mechanism)

In 4 of 4 probes, the delivered body ended with a trailing ARGUMENTS: <text> line iff nothing was substituted. When substitution fired, that trailer was absent. Useful as a detector — a missing trailer means the body was rewritten — but we're labelling it an observed correlation across four probes, not a mechanism we traced. If it holds generally it's a cheap regression assertion.

Shared skill trees multiply the blast radius past one repo

User-level skills are visible to every project on the machine. On the box where this was measured, ~/.claude/skills is a symlink into a single git repository, so one affected SKILL.md exposes every project on that machine, and a git pull propagates it to every machine that clones it. Your closing line — "that only protects one repo" — understates it slightly in the shared-tree case: the unit of exposure is the machine, not the repo.

---

On the requests

Strong agreement with your #1 (per-file opt-out, or better, opt-in binding of declared arguments only). Our downstream mitigation converged on exactly yours independently — we removed every dollar-digit literal from the affected files, hoisted embedded shell out to external scripts, and added a CI guard banning the token class. It took three passes, one site could not be fixed in place at all and had to move its logic out of the skill body entirely, and it protects exactly one machine's tree. That's a lot of work to buy something an engine-side fix gives everyone for free.

One addition we'd suggest for #3: whatever the fix, a loud failure for an out-of-range index would be worth more than silence, even before the scoping question is settled. Under the current behavior there is no configuration in which a user learns this happened.

Caveat on our environment: the measurements above are from 2.1.220. We have not re-probed on 2.1.221, so treat the version as the one measured rather than as a claim about current builds.

Disclosure: this was surfaced and fixed by a Claude Code agent session (Sonnet 5) while patching a production template shared across our internal repo fleet; I reviewed the repro and the claims below before posting.

Confirming on Claude Code 2.1.227, Linux (WSL2, Ubuntu, kernel 6.6.87.2), Node v24.15.0 — still present, well past the 2.1.220/2.1.221 builds already confirmed above. Adding two angles I don't think are covered yet.

A silent-zero failure shape, distinct from truncation/false-pass

Our case is a two-stage classify-then-count awk script (categorize an org's task backlog into columns by section heading, then tally each column) — same family as the !seen[$0]++ and 23/23 examples above, but the corruption disables the classifier rather than the counter:

/^### /  { line = tolower($0); if (line ~ /in flight/) col="inflight"; ... }
/^[ \t]*[-*][ \t]+/ { if (col != "") counts[col]++ }

With $0 rewritten to a constant (the first CLI arg token), tolower($0) becomes tolower("sometoken") — a literal that never matches any section-heading pattern, so col stays "" for the entire run and every category count silently goes to zero, exit 0. Unlike the truncate-to-one or pass-everything shapes already reported, this one reads as "the backlog is empty" — a business-metric failure a human skimming a dashboard is less likely to catch than an obviously-wrong-but-nonzero number, precisely because zero is a plausible value for an empty section.

Blast radius via template propagation, not just shared skill-trees

The comment above notes shared ~/.claude/skills symlinks widen exposure to "the machine, not the repo." We hit a different multiplier: this file is a template deliberately copied by two bootstrap automations into every downstream project (9 separate repos in our case, via cp/contents-API during project scaffolding — not a symlink). The vulnerability reproduces itself at every copy site with no shared code path to patch once — fixing it meant editing the template and separately patching every already-onboarded repo. Any org running a "copy this command/skill into new projects" bootstrap pattern has this exposure scale with fleet size, independent of the shared-tree case already described.

A mitigation note (awk-specific, not general)

For anyone hitting this in awk specifically: rewriting $0/$1 as $(0)/$(1) (parenthesized field-number expression) is byte-different from the literal $N token the substitution keys on, but evaluates identically in awk (verified — same output before/after). This does not generalize to bash — $(0) in a shell script is command substitution (runs a command literally named 0), not the positional parameter. Mentioning only so nobody in this thread copies it into a bash context and gets a different, more confusing failure.

+1 on request #2 (fence exemption) given how naturally shell/awk snippets and their positional/field-reference syntax land inside fences specifically.