Add option to disable 'Command contains quoted characters in flag names' warning

[AndersHeie]

Problem

After a recent Claude Code update, every bash command containing quoted characters in flag values triggers a confirmation prompt with the warning:

Command contains quoted characters in flag names

This happens on completely normal commands like git commit -m "message" or bun run build --flag "value". In previous versions, these commands executed without prompts (assuming they matched the allowlist).

Impact

• Breaks existing workflows — commands that previously matched Bash(git commit *) or Bash(bun run *) allowlist patterns now require manual yes/no confirmation every time.
• Especially disruptive for agentic use — multi-agent orchestration workflows that delegate to subagents are constantly interrupted by these prompts.
• False positive rate is very high — legitimate, safe commands are flagged far more often than actual injection attempts.

Request

Please add one or more of the following:

1. A setting to disable this specific check — e.g., "disableQuotedCharWarning": true in settings.json
2. Respect the existing allowlist — if a command matches an allow pattern, skip the quoted-character check
3. Documentation — explain exactly what patterns trigger this warning so users can reformulate commands to avoid it

Environment

• Claude Code (latest, Feb 2026)
• WSL2 / Linux
• Using project-level settings.json with allowlist + denylist permissions

Current workaround

The only workaround is adding Bash(*) to the allowlist, which defeats the purpose of having granular allow patterns.

[cboos]

Claude Opus 4.6 uses echo "---" all the time to separate command outputs (e.g., file .../aa && echo "---" && file .../ab), so now we get this warning and block all the time as well :-(

[stonematt]

"Command contains quoted characters in flag names" fires too broadly

Problem

The safety check that warns about quoted characters in Bash commands triggers on harmless literal strings, requiring manual approval for commands like:

git log --oneline -5 && echo "---" && git status --short

The prompt says "Command contains quoted characters in flag names" — but "---" is a literal string passed to echo, not a flag name. There's no injection risk.

Impact

This creates unnecessary approval interruptions during normal agentic flow. Users end up adding blanket CLAUDE.md rules to work around it ("never use quotes"), which is a worse outcome than a well-scoped check.

Expected behavior

The check should distinguish between:

• Quoted characters in flag/argument positions (e.g., --flag="$(rm -rf /)") — worth flagging
• Quoted literal strings passed to safe commands like echo — should not trigger

Reproduction

Run any Bash command with a quoted literal, e.g.:

echo "---"
echo "hello world"
printf "%s\n" "done"

All trigger the approval prompt unnecessarily.

[m-atoms]

Given how widely Claude Code is used and how disruptive this is to the default workflow, I'm surprised there isn't more activity in here. Is there an easy fix I'm missing? I added CLAUDE.md rules in the meantime:

 - Bash commands: never chain with `&&` — use separate parallel Bash calls instead. Claude Code's compound-command 
security check ([#16561](https://github.com/anthropics/claude-code/issues/16561)) prompts even when each component 
is individually allowed. Also avoid quoted strings resembling flags (e.g., `echo "---"`) which trigger "quoted characters 
in flag names" warnings ([#27957](https://github.com/anthropics/claude-code/issues/27957)).

[mrballcb]

Using beans is also affected by this. While working, beans continually updates its markdown with things like:

beans update helm-chart-hnlf --body-replace-old "- [ ] Update all container resource specifications to support resourceSizing" --body-replace-new "- [✅ ] Update all container resource specifications to support resourceSizing"

I can no longer tab away from anything working with agents because it prompts for every single step across each agent. I'm not willing to --dangerously-skip-permissions for some things.

[Stanzilla]

It fails on things like this for me all the time:

[jonas-debeuk]

also getting blocked a lot by this - even dangerously sku permissions flag didn't seem to help 🤔

[DeanBaron]

also getting blocked a lot by this. I run CLIs that accepts JSON arguments, this makes CC always request permissions which slows down work significantly.

[outbound]

Same. Glad not the only one.