Opus 4.7 defaults to Bash tool on Windows despite CLAUDE_CODE_USE_POWERSHELL_TOOL=1; system prompt injects 'Shell: bash'

Summary

On Windows, with CLAUDE_CODE_USE_POWERSHELL_TOOL=1 set and explicit CLAUDE.md directives to prefer the PowerShell tool, Opus 4.7 still reaches for the Bash tool by default for command execution. This is a behavioral regression compared to Opus 4.6, which followed CLAUDE.md shell preferences more reliably.

Environment

• OS: Windows 11 Enterprise (native, no WSL)
• Claude Code: current stable (v2.1.x series)
• Model: claude-opus-4-7 (1M context)
• CLAUDE_CODE_USE_POWERSHELL_TOOL: set to 1 in shell profile (process-level, confirmed)
• CLAUDE.md: contains explicit directive: "Always use the PowerShell tool for command execution, not the Bash tool." with documented exceptions (agent-browser, venv activation, .sh scripts)
• Both Bash and PowerShell tools are registered simultaneously.

Observed diagnosis (root cause)

Inspecting the system prompt delivered to the model on Windows, the harness injects this line verbatim:

Shell: bash (use Unix shell syntax, not Windows — e.g., /dev/null not NUL, forward slashes in paths)

This line is injected even when CLAUDE_CODE_USE_POWERSHELL_TOOL=1 is set and the PowerShell tool is registered. It creates a direct conflict:

• System prompt declares the shell as bash (highest instruction weight).
• CLAUDE.md declares PowerShell as the preferred tool (lower weight — injected as user context).

Opus 4.7 — which multiple public writeups describe as following instructions more literally than 4.6 — honors the system prompt's shell declaration over CLAUDE.md's preferences. Opus 4.6 was "looser" and inferred intent from CLAUDE.md more often; 4.7's stricter instruction-following amplifies this existing conflict rather than resolving it.

Why this is a regression, not just an existing bug

This has been reported before (#6453, #45831, #28670, #15471), but the severity is materially worse on 4.7. Users who had working 4.6-era CLAUDE.md configurations are experiencing sudden drift to Bash tool use without changing anything on their end. The model isn't "wrong" — the harness is sending conflicting signals and 4.7 resolves the conflict differently than 4.6 did.

Proposed fix (harness-side, not model-side)

When CLAUDE_CODE_USE_POWERSHELL_TOOL=1 is set on Windows, the system prompt should either:

1. Relabel the shell line to Shell: PowerShell (use PowerShell syntax...), OR
2. Omit the Shell: line entirely and let the tool list + CLAUDE.md speak for themselves, OR
3. Inject Shell: PowerShell with a one-line exceptions note pointing users to use the Bash tool for POSIX-requiring cases.

Option 1 is the cleanest — it mirrors the tool that's actually registered.

Additionally, consider unregistering the Bash tool entirely when the PowerShell tool is active (gated by a separate env var like CLAUDE_CODE_DISABLE_BASH_TOOL=1 for users who want hard enforcement).

Workaround

Users can block the Bash tool via settings.json permissions denylist, but this breaks legitimate Bash-only use cases (bashrc-defined functions, POSIX-only scripts). A scalpel workaround doesn't exist today.

Related issues

• #6453 — "CC attempts to use Bash in a Windows PowerShell environment despite all prompts otherwise"
• #45831 — "Claude defaults to bash/Unix syntax on Windows instead of PowerShell"
• #28670 — "Claude Code repeatedly uses Bash syntax (extglob) on Windows PowerShell and fails to adapt"
• #15471 — Windows shell compatibility

This issue adds: confirmation that the behavior worsened with the 4.7 release and a specific root-cause identification (the Shell: bash system prompt line overriding CLAUDE.md).