allowed-tools: shell does not auto-approve compound commands or unlisted binaries

[loganrosen]

Describe the bug

allowed-tools: shell in SKILL.md frontmatter does not fully auto-approve shell commands. Two issues:

1. Compound commands always prompt: Any command using ;, &&, |, >, or multi-statement syntax triggers a permission prompt, even when every individual command in the chain (e.g., python3, gh, echo) would be auto-approved on its own.

2. Unlisted binaries always prompt: Commands not on the internal allowlist (e.g., custom binaries installed on $PATH) always prompt regardless of allowed-tools: shell. Only a specific set of known commands (git, gh, python3, echo, whoami, etc.) are auto-approved.

Expected behavior

When a skill declares allowed-tools: shell, ALL shell commands should be auto-approved — both compound commands and commands using any binary available on $PATH. The user opted into trusting shell execution for this skill.

Affected version

1.0.42

Steps to reproduce

Create a skill with allowed-tools: shell in the YAML frontmatter:

---
name: test-skill
allowed-tools: shell
---

# Test

Run this command:

\`\`\`bash
echo "hello" && echo "world"
\`\`\`

Invoke the skill. The echo "hello" && echo "world" command will prompt for approval even though:

• allowed-tools: shell is declared
• Both commands are just echo

Similarly, a command like mycustomtool --version (where mycustomtool exists on $PATH) will always prompt.

Additional context

• Simple single commands using known binaries (e.g., echo "hello") DO auto-approve correctly
• The allowlist appears to include: git, gh, python3, echo, whoami, curl, node
• This makes it impossible to write skills that execute without user interaction, since LLMs naturally construct compound commands
• Skills that need to set variables and then use them (e.g., GH_USER="foo"; gh api ...) always prompt

[loganrosen]

I re-tested this against the current CLI build using the exact repro from the issue: a skill with allowed-tools: shell running echo "hello" && echo "world".

The command executed without a shell approval prompt and printed both lines as expected. I also checked a similar scenario with command names that are not part of the common built-in command set, and I couldn't reproduce a prompt there either.

Closing as not reproducible in the current version. Some unrelated safety prompts may still appear for separate reasons, but those are distinct from this issue's repro.