Sandbox permission prompts are excessive and unavoidable for common development patterns

Description

During a single coding session, the user was prompted for permission approval 15+ times for commands that are standard development patterns. Many of these cannot be resolved by adding allow rules because the sandbox flags the command structure, not the command itself.

Environment

• Claude Code on macOS (Darwin 25.3.0)
• Shell: zsh
• Model: Claude Opus 4.6

Commands that triggered prompts despite relevant allow rules existing

1. Piped commands with python3 -c and newlines

Flagged as "potential obfuscation" or "quoted newline followed by #-prefixed line"

some-cli get-data | python3 -c "
import json, sys
# Process fields
data = json.load(sys.stdin)
"

python3:* is in the allow list. The flag is on the structure (newlines + # comments), not the command.

2. node -e with multiline inline scripts

Same issue. node:* is allowed but the multiline content triggers "potential obfuscation."

3. Empty quotes before dashes

Flagged as "potential bypass"

my-cli edit-issue TASK-123 "" "" "" --parent EPIC-456

my-cli:* is in the allow list.

4. npm run dev &

Flagged as "shell operators that require approval." npm:* is allowed. The & operator triggers it regardless.

5. for loops

Flagged as "multiple commands"

for i in 1 2 3 4 5; do curl -s ... && break; sleep 3; done

6. wc command

Required adding to the allow list even though it's a read-only utility with no side effects.

7. Consecutive quote characters

Flagged as "potential obfuscation"

content.replace('\u201c', '\"').replace('\u201d', '\"')

The core problem

The allow list matches on command prefix (Bash(python3:*)), but the sandbox flags are on command structure (newlines, # comments, empty quotes, &). There's no way to allow these structural patterns. The user must approve every single one manually, even when the underlying command is already trusted.

Impact

• Breaks autonomous workflows — the user told Claude to work independently and came back to find it blocked on prompts
• Erodes trust — the user has to closely monitor every action instead of delegating
• Creates frustration — the same patterns get flagged repeatedly with no way to permanently allow them

Expected behavior

• If python3:* is allowed, piping into python3 -c with newlines should be allowed regardless of content structure
• If my-cli:* is allowed, passing empty string arguments shouldn't trigger "potential bypass"
• If npm:* is allowed, npm run dev & shouldn't require separate approval for the &
• There should be a way to allow structural patterns like &, for loops, and piped multiline scripts globally

Suggested improvements

1. Allow rules should take precedence over structural heuristics — if the user trusts python3:*, they trust it with newlines too
2. Add structural allow rules like Bash(operator:&) or Bash(structure:multiline)
3. Read-only commands (wc, cat, head, tail, file, stat) should be allowed by default
4. When a prompt is approved with "Yes, and don't ask again", the derived rule should cover the structural pattern, not just the exact command string