Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Selecting "Always Allow" for a compound Bash command (quoted path with spaces + pipe + && + .exe) writes an entry to settings.local.json, but Claude Code continues to prompt for permission on every subsequent execution.

Command that triggers the issue:

"C:/Program Files/LLVM/bin/clang.exe" -std=c11 -Wall -g trigex.c -o trigex.exe 2>&1 | tail -5 && ./trigex.exe 2>&1

This command has multiple characteristics that likely each contribute to matching failure:

1. Executable path contains spaces → must be quoted with double quotes
2. Contains pipe operator (|) and output redirection (2>&1)
3. Compound command chained with &&
4. Uses .exe extension on Windows

What Should Happen?

After selecting "Always Allow" once, the same command should be auto-approved on all future executions without prompting again.

Steps to Reproduce

1. Ask Claude Code to run:

   "C:/Program Files/LLVM/bin/clang.exe" -std=c11 -Wall -g trigex.c -o trigex.exe 2>&1 | tail -5 && ./trigex.exe 2>&1
   

2. When prompted, select "Always Allow"
3. Verify the permission was written to .claude/settings.local.json
4. Ask Claude Code to run the exact same command again
5. Observe: permission prompt appears again despite the entry in settings.local.json

Evidence

• settings.local.json is updated after step 2 (the permission IS written — unlike [BUG] Permission "Always Allow" Selection Not Persisted - Prompts Repeat Every Execution #16762)
• The written permission entry is likely the full literal command string (see Permission allow-list captures entire literal commands instead of extracting command patterns #21845 for the pattern-vs-literal issue)
• The literal string fails to re-match on the next execution, presumably because:
  • The .exe path resolver expands the quoted path before pattern matching ([BUG] Bash permission pattern fails to match commands with .exe extension on Windows #27537 hypothesis)
  • And/or the compound command (|, &&, 2>&1) is not parsed consistently between storage and matching

Related Issues

• [BUG] Bash permission pattern fails to match commands with .exe extension on Windows #27537: .exe pattern matching fails on Windows (single command, no pipes tested)
• Permission allow-list captures entire literal commands instead of extracting command patterns #21845: Permission allow-list stores full literal commands instead of patterns (macOS)
• [BUG] Permission "Always Allow" Selection Not Persisted - Prompts Repeat Every Execution #16762: "Always Allow" not persisted to settings at all (different root cause — writing fails)

This report extends all three: on Windows, compound commands with a quoted .exe path and pipes are stored as literals (#21845 behavior), AND the .exe path-with-spaces matching fails (#27537 behavior), making it impossible to use "Always Allow" for any realistic compile-and-run workflow.

Error Messages/Logs

No error shown — Claude Code silently re-prompts without indication that the stored permission failed to match.

Claude Model

claude-sonnet-4-6

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.50 (Claude Code)

Platform

Anthropic API

Operating System

Windows 10 Pro (Build 10.0.19045)

Terminal/Shell

Windows Terminal / Git Bash (bash)

Additional Information

This is particularly disruptive for iterative development workflows (e.g., compile + run cycles) where the same compound command is executed many times per session. The only current workaround is manually approving every single invocation.