Personal-config context probe fails to load on Claude Code 2.1.228 — "Contains expansion" — breaks every skill with a Project Context block (including han-feedback itself)

[VikiAnn]

Title: Personal-config context probe fails to load on Claude Code 2.1.228 — "Contains expansion" — breaks every skill with a Project Context block (including han-feedback itself)

Summary

Every han skill that reads personal config carries this line in its ## Project Context block (vendored byte-identical from config-rule.md into every plugin):

- personal config directory: !`echo "${CLAUDE_CONFIG_DIR:-$HOME/.claude}"`

On Claude Code 2.1.228, invoking any such skill fails immediately at load with:

Shell command permission check failed for pattern "!`echo "${CLAUDE_CONFIG_DIR:-$HOME/.claude}"`": Contains expansion

This is a hard skill-load abort, not a graceful degrade. It reproduces on han-planning:plan-implementation, han-communication:readability-guidance, han-communication:edit-for-readability, and han-feedback:han-feedback itself — so users can't even use han-feedback to report this without going around it via gh directly, as I'm doing here.

Evidence chain

• Probe origin: commit 5fac8e8 (2026-07-30, "feat(han-communication): prove the personal config probe shape loads", River Lynn Bailey). Its own validation artifact, docs/plans/user-level-han-config/artifacts/probe-check-result.md, shows the probe was tested live through a real skill invocation and loaded/resolved correctly at the time — this wasn't an untested assumption.
• Same-day partial fix: commit e483783 replaced the content-read probe (cat .../.han/config.md) with the Read tool, but explicitly kept the directory-resolution probe (echo "${CLAUDE_CONFIG_DIR:-$HOME/.claude}") — the commit's own note says "that probe survives."
• Extended, not removed: commit 0405583 (2026-08-05) extended the surviving probe to also check AGENT_CONFIG_DIR, nesting the expansion deeper: ${AGENT_CONFIG_DIR:-${CLAUDE_CONFIG_DIR:-$HOME/.claude}}.
• Blast radius: the probe is vendored byte-identical into every plugin's config-rule.md and repeated in every skill with a Project Context block — plan-implementation, readability-guidance, edit-for-readability, coding-standard, investigate, han-feedback, etc. All of them break identically.
• Root cause is Claude Code–side, not a han regression. Decompiled strings from the installed Claude Code binary (v2.1.228) show the !command`` skill-probe execution path (function v8e) routes through the same permission-check function used for live Bash tool calls (`Zx`), which now hard-rejects any pattern containing shell expansion — unconditionally, with no settings.json override available. (Confirmed against a real `settings.json`: no permission-mode override or allow rule touches this; the rejection matches on the literal pattern text, so an allow-list entry containing the same expansion would hit the identical rejection.)
• Timing: Claude Code shipped 2.1.221 through 2.1.228 between 2026-08-03 and 2026-08-11 — a window after han's 2026-07-30 validation (there was a ~10-day gap before that, 2.1.220 → 2.1.221, so the probe was almost certainly validated against 2.1.220 or older). 2.1.228's own changelog (released 2026-08-11) calls out related hardening: "on your machine their bodies don't run ! commands or expand @ files" for skills synced from claude.ai — a different provenance tier than han's git-marketplace install, but evidence Claude Code is actively tightening this exact surface right now.

Conclusion: the probe was correct and validated when written. A Claude Code security tightening landed afterward — most plausibly within the last ~8 days, quite possibly the 2.1.228 release itself — and silently broke it. Han has no fallback or user-facing note for this failure mode; it aborts skill load outright.

Impact

High severity. Not a personal-config edge case — it blocks skill load for every user on affected Claude Code builds, regardless of whether they have a personal .han/config.md at all.

Suggested fix direction

The personal-config-directory resolution can't safely rely on !command`` shell expansion under harnesses that reject expansion-bearing probe patterns. Needs either a static/non-expansion probe form, or a way to read CLAUDE_CONFIG_DIR/`AGENT_CONFIG_DIR` that doesn't route through the load-time shell-probe permission check (e.g., resolve it the same way the personal `.han/config.md` content itself was moved to the Read tool in `e483783`).

Environment

• Claude Code 2.1.228 (native binary install, not the npm wrapper)
• han plugin marketplace install, v5.2.0 (ref han-v5.0.0-alpha-1)
• macOS, Darwin 25.5.0
• First observed via han-planning:plan-implementation and han-communication readability skills; confirmed also breaks han-feedback:han-feedback

[VikiAnn]

Current workaround is having my Claude patch the local han plugin files to replace the personal config directory value:

OLD = '- personal config directory: !`echo "${CLAUDE_CONFIG_DIR:-$
HOME/.claude}"`'
NEW = '- personal config directory: /Users/viki/.claude'
# some python to loop over each han file in the local claude plugins cache and replace the OLD with the NEW

That seems to be working fine, but obviously it'll get clobbered with plugin updates etc.