[BUG] Windows Git Bash: static analysis false-positives on read-only cd-compound commands cause constant, unsuppressable permission prompts (since 2.1.232 / auto-mode rollout) #86619

Environment

• Claude Code 2.1.232 (native install), Windows 11 Pro, Git Bash shell
• Observed independently on two separate machines (different users, different hardware, same day)
• Onset correlates exactly with 2.1.232 arriving via the native launcher's startup self-update (version files on disk: 2.1.229 → 13 Aug 08:30, 2.1.231 → 13 Aug 09:41, 2.1.232 → 14 Aug 06:01 local; prompts began within hours on both machines), compounding with the 14 Aug auto-mode default rollout.

What happens

On Windows with Git Bash, any Bash command of the shape cd "<absolute path>" && <anything not fully literal> now fails static analysis and falls through to a manual "Do you want to proceed?" prompt. We have collected four distinct reason wordings verbatim:

1. Contains simple_expansion On Windows with Git Bash, the final working directory of this cd-compound cannot be statically determined, so relative write targets cannot be checked for Cygwin-emulated symlinks and this request cannot be delegated to the auto-approval classifier.

2. Redirect target contains $(cmd) output — path is runtime-determined On Windows with Git Bash, [same continuation]

3. Contains brace with quote character (expansion obfuscation) On Windows with Git Bash, [same continuation]

4. Compound command contains cd with write operation - manual approval required to prevent path resolution bypass On Windows with Git Bash, [same continuation]

The clearest false positive

Reason 4 above was produced by this command, which contains no write operation of any kind — two sed -n reads and a pipe:

cd "C:/Users/<user>/<project>" && sed -n '/pattern-a/,/pattern-b/p' static/app.js | sed -n 1,60p

Other innocuous shapes reliably prompting:

# read-only loop → "Contains simple_expansion"
cd "C:/Users/<user>/<project>" && for v in 1.60.0 1.58.0; do echo "== $v"; uv run --with "pkg==$v" python -c "..." 2>&1 | tail -2; done

# write to a FULLY ABSOLUTE literal temp path via variable → "Redirect target contains $(cmd) output"
cd "C:/Users/<user>/<project>" && S="C:/Users/<user>/AppData/Local/Temp/claude/<session>/scratchpad" && tool > "$S/out.json" 2>&1

# heredoc script to an absolute literal path → "expansion obfuscation"
cd "C:/Users/<user>/<project>" && cat > "C:/.../scratchpad/probe.py" <<'PY'
...
PY

Note the cd target is always a quoted absolute path, so the "final working directory cannot be statically determined" claim is itself questionable for these commands.

Why the friction is severe

• Subagents and workflows on Windows generate cd "<abs>" && ... compounds constantly (it is the natural way to scope a command to a project). Users are seeing dozens of prompts per hour during normal agentic work.
• These prompts never offer "don't ask again" — presumably because a rule can't be derived from a command the analyser couldn't parse — so the friction cannot be reduced from the prompt itself. Hand-written Bash(cmd *) allow rules in settings help, but only apply to sessions started after they are saved.
• Because this lands together with the auto-mode default rollout, every Windows + Git Bash user receives the behaviour change at once, with no version pinning available on the native installer (it self-updates at launch even with "autoUpdates": false).
• Related existing reports: [BUG] autoAllowBashIfSandboxed bypassed for commands containing shell expansions and several other constructs #43713 (expansions defeat auto-allow), [BUG] Windows: permission prompt generates backslash allow-rules that never match forward-slash Bash commands #46783 (Windows "always allow" writes backslash rules that never match), bypassPermissions defaultMode and --permission-mode flag ignored; session stays in auto mode (since 2026-08-14 auto-mode rollout) #86478 / Auto mode classifier denies tool calls in bypassPermissions sessions (v2.1.231) #86451 (auto-mode rollout overriding chosen permission modes).

Expected behaviour

1. A command whose parts are all read-only (sed -n, grep, head, tail, pipes, no redirects) should pass static analysis regardless of cd, or at minimum remain delegable to the auto-approval classifier.
2. A command containing no redirect and no write verb should never be described to the user as containing a "write operation".
3. cd to a quoted absolute path should establish the working directory for the analysis of the rest of the compound.
4. Where the analyser can identify the offending sub-part (it already prints "The following part requires approval: …"), the prompt should offer a scoped "don't ask again".

Happy to provide more captures — we are logging every distinct wording.