claude-code - 💡(How to fix) Fix Slash-command skills with !`...` frontmatter expansions fail to load when sandbox cannot create network namespace

Summary

Slash-command-style skills whose frontmatter uses inline !...`` bash substitutions fail to load in environments where the harness sandbox (bwrap) cannot create its network namespace. The skill never runs — the error surfaces as Shell command failed for pattern "!<cmd>": bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted and the invocation aborts before any skill content is delivered.

Reproduction

Invoke any slash-command skill whose frontmatter contains a !...`` substitution from an environment where bwrap can't set up its sandbox's loopback interface (constrained containers, restricted user namespaces, certain CI runners).

The clearest reproducer is commit-commands:commit-push-pr from the Anthropic-maintained claude-plugins-official marketplace. Its frontmatter is:

---
allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), Bash(git status:*), Bash(git push:*), Bash(git commit:*), Bash(gh pr create:*)
description: Commit, push, and open a PR
---

## Context

- Current git status: !`git status`
- Current git diff (staged and unstaged changes): !`git diff HEAD`
- Current branch: !`git branch --show-current`

Each !...`` is evaluated by the harness before the skill is injected, via a sandboxed bash invocation. If bwrap fails to set up its sandbox, every expansion fails.

Two consecutive invocations during the same session produced:

Shell command failed for pattern "!`git branch --show-current`": [stderr] bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
Shell command failed for pattern "!`git status`": [stderr] bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted

Why it's the sandbox

In the same session, the assistant's own Bash tool calls failed with the identical bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted until dangerouslyDisableSandbox: true was passed. Once that flag was added, every subsequent bash call succeeded. The skill-loader path has no equivalent escape hatch — when a slash-command skill is invoked, its frontmatter substitutions go through the default sandboxed bash and there's no way for the assistant or the user to opt out for that one expansion.

Skills served as static prompt blocks (e.g. superpowers:*, the flow:* plugin's SKILL.md files, all of which contain zero !...`` substitutions) load fine because the harness never invokes sandboxed bash for them.

Impact

• Affects every slash-command skill that uses !...`` frontmatter substitutions. Within the official marketplace this is at least commit-commands:commit-push-pr and commit-commands:commit.
• The failure mode is "skill doesn't load" with no fallback. The caller has to know to drop down to raw commands (git push, gh pr create) instead.
• Hits real environments: constrained containers, certain CI runners, and any host where bwrap doesn't have the privileges it needs to set up its netns.

Possible fixes (in rough order of effort vs. payoff)

1. Better error message on bwrap failure — make it obvious that the skill failed because of host-level sandbox restrictions, not because of a problem with the skill itself. Today the error doesn't mention the sandbox at all from the caller's perspective.
2. Sandbox-skip flag for frontmatter expansions — when the harness can't satisfy the sandbox, fall back to running the expansion without bwrap (with a warning), or prompt the user once per session.
3. Skill-side workaround — move git-state collection out of frontmatter !...`` and into the skill body, so the assistant runs the commands itself via the Bash tool. Eliminates the dependency on sandboxed expansion. Could be patched in claude-plugins-official for the two affected commands.

Environment

• OS: Linux 6.8.0-111-generic
• Shell: fish
• Harness: Claude Code (model claude-opus-4-7[1m])
• Plugin path: /home/agent/.claude/plugins/cache/claude-plugins-official/commit-commands/unknown/commands/commit-push-pr.md