Bash permission checks and approval messages revised

What

When Claude wants to run a shell command through the Bash tool, Claude Code decides whether to run it right away, ask you first, or block it. Several parts of that decision, and the messages it shows, changed in this release.

• Quoted [, ? and * characters are now marked so they are not read as glob wildcards (patterns that match many file names) when commands are split up for matching.
• The step that strips leading environment assignments (such as FOO=bar command) can now skip a normalisation pass through new wrappers.
• Git permission checks now receive the raw command and gained new sub-checks, and one condition was dropped from the check for safe commands.
• Docker commands with arguments that look like a tilde-user path (for example ~name), or that contain both ~ and {, are no longer auto-allowed as read-only. They now prompt instead, both in the read-only classifier and in docker's safe-flag checks.
• A file write or output redirection that is not auto-allowed now gets one of two prompts. A path inside the working directories says it "needs approval. The path is inside the working directories". A path outside them says it is outside the working directories and that allowing runs the command as written. Read operations and rule-based denials keep the old "was blocked. For security" text.
• When every command in a pipeline is allowed, the reason now says "All pipeline commands are individually allowed, some only by the read-only allowlist" when some were allowed only by the built-in read-only list.
• The prompt for the & background operator is unchanged.

Why

Changes to permission matching can turn a command that used to run without asking into one that asks, or the other way round, especially for quoted wildcards, git and docker. The old write message said "blocked" even when you were only being asked, which made writes inside your project look like hard failures; the new wording makes clear you are being asked to approve.