Always allow on multi-line commands saves broken/useless permission fragments

Description

When a user selects "Always allow" (or presses a) for a multi-line bash command, Claude Code saves each line as a separate permission rule. This results in broken, useless fragments that pollute the settings file.

Example

When approving this command:

if [ -f ~/.config/yazi/yazi.toml ]; then
  cat ~/.config/yazi/yazi.toml
else
  echo "No yazi.toml found"
fi

The following gets saved to .claude/settings.local.json:

"Bash(if [ -f ~/.config/yazi/yazi.toml ])",
"Bash(then cat ~/.config/yazi/yazi.toml)",
"Bash(else echo \"No yazi.toml found\")",
"Bash(fi)"

Why this is a bug

1. These fragments will never match any real command - no one runs fi as a standalone command
2. They provide no security benefit - they don't actually permit the original multi-line command to run again
3. They pollute settings files over time, requiring manual cleanup
4. Similar issue occurs with for/while loops and other shell constructs

Expected behavior

One of:

1. Don't offer "Always allow" for multi-line commands (only "Allow once" / "Allow for session")
2. Show a warning explaining multi-line commands can't be saved as reusable rules
3. Save the entire command as a single rule (specific but at least functional)
4. Detect shell constructs (if/for/while/case) and handle appropriately

Environment

• Claude Code CLI
• Linux (also likely affects macOS)