[FEATURE] Desktop: let the integrated terminal use Git Bash on Windows (currently hardcoded to powershell.exe)

Status Closed — duplicate
Reported on v2.1.219
Maintainer reply None cached
Activity 2 comments · opened Aug 4, 2026 · closed Aug 20, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Problem
On Windows, the Code tab's integrated terminal always runs Windows PowerShell 5.1. The shell is hardcoded in the app bundle — in resources/app.asar (v1.24012.11.0):

function L(){return{shell:"powershell.exe",args:[]}}
There is no way to change it:

No terminalShell / shellPath / terminal-profile key exists in the app bundle or in the Claude Code settings schema.
SHELL is only consulted on darwin; on win32 it is ignored (only forwarded to child env).
ComSpec and the Windows Terminal default profile are not consulted.
defaultShell in settings.json does not apply — its own schema description scopes it to "Default shell for input-box ! commands".
CLAUDE_CODE_GIT_BASH_PATH only points the Bash tool / worktree code at bash.exe.
Installing PowerShell 7 does not help, because it ships as pwsh.exe and powershell.exe remains 5.1 permanently.
Why this bites specifically
Claude's own Bash tool on Windows is Git Bash, so Claude naturally writes POSIX commands. When it hands the user the same command in a fenced ```bash block, the Run button pastes it into PowerShell 5.1, where it fails. Example — clicking Run on:

rm -rf /c/Users/me/source/repos/some-repo
produces:

Remove-Item : A parameter cannot be found that matches parameter name 'rf'.

  • CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException
  • FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand

PowerShell 5.1 makes this sharper than a normal bash-vs-PowerShell mismatch: && is a parse error there, not merely a semantic difference —

The token '&&' is not a valid statement separator in this version.
so even trivial chained commands like npm ci && npm test fail on the Run button.

The current workaround is to type bash in the terminal pane to drop that tab into Git Bash, which has to be repeated for every new tab.

Notably, the desktop app already requires Git for Windows to be installed (the docs say to install it and restart before first use), so bash.exe is guaranteed present on every Windows machine running the app.

Proposed Solution

Requests
A setting for the integrated terminal's shell on Windows — e.g. "terminal": { "shell": "bash" | "powershell" | "<absolute path>" } — reusing the existing Git Bash discovery logic (CLAUDE_CODE_GIT_BASH_PATH, then %ProgramFiles%\Git\bin\bash.exe, etc.) that the Bash tool already has.
Prefer pwsh.exe over powershell.exe when present, so users who install PowerShell 7 get a shell where && at least parses.
Consider honoring the fence language on the Run button — a ```bash block routed into PowerShell is a guaranteed failure. Either run it in bash when available, or warn/disable Run when the fence language doesn't match the terminal's shell.
Environment
Claude desktop 1.24012.11.0 (x64, MSIX)
Bundled Claude Code 2.1.219
Windows 11 Pro 26100
Windows PowerShell 5.1.26100.8875
Git for Windows present at C:\Program Files\Git\bin\bash.exe

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗