Regression: compound && commands prompt for approval even when all segments are individually allowlisted (v2.1.158–2.1.168, Windows)

Summary

When all subcommands in a &&-chained compound command are individually covered by entries in permissions.allow, the compound command still triggers a manual approval prompt. This contradicts the documented behavior that compound commands are auto-approved when each subcommand independently matches an allow rule.

The regression correlates with version 2.1.158 and persists through 2.1.168 (latest at time of filing). It is Windows-specific — macOS users in the same fleet running identical commands do not exhibit this behavior.

Environment

• OS: Windows 10 (builds 26100–26200)
• Claude Code versions affected: 2.1.158 through 2.1.168 (regression onset ~2.1.158)
• Entrypoints: CLI and VS Code extension
• macOS: Not affected in the same fleet

Steps to Reproduce

Configure permissions.allow in enterprise settings with (at minimum):

["Bash(cd:*)", "Bash(dotnet:*)", "Bash(grep:*)", "Bash(find:*)", "Bash(git:*)"]

Then run any of the following compound commands from Claude Code on Windows 10:

# All segments covered by Bash(cd:*), Bash(dotnet:*), Bash(grep:*)
cd /project && dotnet build src/Project.csproj --no-restore -v minimal 2>&1 | grep -E "error CS|Error"

# All segments covered by Bash(find:*), Bash(grep:*)
find . -name "*.cs" -type f | grep -v obj | head -20

# All segments covered by Bash(git:*)
git push

# All segments covered by Bash(cd:*), Bash(git:*)
cd /repo && git log --oneline -5

Observed Behavior

An approval prompt appears for the compound command even though every constituent subcommand is covered by an entry in the allowlist. After approving with "Yes, don't ask again", the permanent approval is sometimes also not honored in subsequent sessions (see related companion issue).

Expected Behavior

Per the permissions documentation — "A rule must match each subcommand independently" — compound commands where every segment independently matches an allow rule should be auto-approved without any prompt.

Evidence

• Approximately 650 occurrences over 15 days across ~20 distinct Windows machines.
• A spike in "covered-but-prompted" events correlates strongly with version 2.1.158, suggesting this version introduced the regression.
• The behavior persists through v2.1.168 (latest at time of filing).
• macOS users in the same fleet running the same commands show no equivalent pattern over the same period — strongly suggesting a Windows-specific code path is involved.

Additional Notes

• The pattern spans multiple command families (cd, dotnet, grep, find, git) — the root cause is not specific to any one command but to the compound-command evaluation logic itself.
• The | (pipe) operator may also be involved in some cases (e.g., find ... | grep ...), which could indicate the issue affects both && chains and pipelines when evaluating against the allowlist.
• Selecting "Yes, don't ask again" on the approval prompt does not reliably suppress future prompts, compounding the user impact.

Related

• Companion issue: user_permanent approval for git push not persisting across sessions on Windows (v2.1.161–2.1.162) — may share a Windows-specific permission evaluation root cause.
• Previously reported: #28183 (compound commands of individually-allowed commands prompt with an incorrect safety reason).