[BUG] v2.1.232 Windows/Git Bash: auto mode floods manual-approval prompts — false "Cygwin-emulated symlink" positives and "cannot be statically determined" for heredoc / cd-compound writes

Environment

• Claude Code v2.1.232 (regression started with this version; v2.1.229 was fine)
• Windows 11 Pro 10.0.26200, Bash tool = Git Bash (MSYS)
• Permission mode: auto mode ("Allowed by auto mode classifier" shown for most commands)
• Heavy subagent usage (parallel general-purpose agents running Bash)

Summary

After updating to 2.1.232, sessions in auto mode started showing a large number of manual approval dialogs for ordinary Bash commands issued by subagents (and some by the main agent). The changelog entry that appears related:

Fixed a Windows permission bypass where Git Bash followed Cygwin-style symlinks that path validation saw as regular files; writes through them now require permission approval

Two distinct dialog messages are shown:

Variant A — claims a symlink traversal that does not exist:

Path traverses a Cygwin-emulated symlink (Git Bash follows it, Node does not) — manual approval required

Example flagged command (subagent): heredoc write to the session scratchpad, absolute Windows path:

cat << 'PYEOF' > "C:\Users\<user>\AppData\Local\Temp\claude\<project>\<session>\scratchpad\write_b2.py"
...python source...
PYEOF
python "C:\Users\<user>\AppData\Local\Temp\claude\...\write_b2.py"

I verified there is no symlink of any kind in that path:

• ls -ld on every path component: all plain directories (drwxr-xr-x)
• cmd /c dir /aL on each level: no junctions/symlinks found
• cmd /c dir /s /aS (SYSTEM-attribute files that MSYS treats as Cygwin symlinks): none

Variant B — refuses to statically resolve cwd, so skips the auto-approval classifier:

This Bash command contains multiple operations. The following part requires approval: SC="C:/…/scratchpad" && cd "$SC/kataB" && python dump_formulas.py 2>&1; grep -c "^F|" formulas.txt; … 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.

Command shapes that trigger the prompts (observed in the field)

From two real work sessions today (374 Bash calls total, 38 of them stalled ≥20 s waiting for approval, worst cases 8–15 minutes because several parallel subagents queued up on dialogs):

1. Heredoc file writes — cat > file << 'EOF' / cat << 'EOF' > file / python << 'EOF' — even when the target is an absolute path (both C:\... and /c/... spellings)
2. cd <dir> && ... > relative_file compounds, especially with a shell variable in the cd target
3. Writes to /tmp/...
4. Multi-line compounds where cd and the write happen on different lines

These shapes are extremely common in normal agent work (writing a small Python script to a scratchpad and running it), so in practice auto mode degrades to constant manual approvals whenever subagents do file-mediated work.

Expected behavior

• Variant A should not fire when no component of the resolved path is a Cygwin-emulated symlink (regular directories all the way down).
• Variant B: when the cd-compound is built only from string literals and variables defined in the same command (SC="literal" && cd "$SC/sub"), the final cwd is statically determinable by constant propagation; and heredoc redirects to absolute paths should not need cwd resolution at all.

Notes

• Could not reproduce Variant A/B from a different session on the same machine (same 2.1.232, same command shapes, both parent and subagent) — the trigger seems to depend on some session state or permission-mode detail; the affected sessions consistently show it many times per hour.
• No existing issue mentions "Cygwin-emulated symlink" as of 2026-08-14.