[BUG] Windows Desktop integrated terminal hardcodes powershell.exe → "Shell exited" (CreateProcess error 1260) when PowerShell 5.1 is blocked by policy

Status Open
Reported on v2.1.211
Maintainer reply None cached
Activity 1 comment · opened Jul 17, 2026

Preflight Checklist

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

What's Wrong?

The integrated (in-app) terminal in Claude Desktop for Windows fails to launch. It shows
"Shell exited." immediately, and clicking Restart Shell repeats the same failure.

Root cause (traced in the shipped app.asar): the local terminal shell resolver is
hardcoded to Windows PowerShell 5.1 with no fallback and no override:

function L(){return{shell:"powershell.exe",args:[]}}

spawned via node-pty as p = d ?? {...L(), cwd:a} (the d branch is only for SSH sessions).
The bare name powershell.exe resolves to C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.

On managed Windows fleets that have retired/blocked Windows PowerShell 5.1 via Group Policy
(AppLocker/WDAC), the OS refuses to create that process, so the PTY dies instantly. This
happens even though PowerShell 7 (pwsh.exe) and Git Bash are installed and on PATH.

No configuration can work around it. I enumerated every managed-settings key in the binary
and reviewed both the "Deploy Claude Desktop for Windows" and "Enterprise configuration"
support articles - there is no shell/terminal setting. The terminal also does not consult
CLAUDE_CODE_GIT_BASH_PATH, defaultShell (which only affects input-box ! commands),
pwsh.exe, or process.env.SHELL.

What Should Happen?

The integrated terminal should open a working shell on Windows without requiring PowerShell 5.1.

Suggested resolution order for the terminal's shell resolver:

  1. Prefer pwsh.exe (PowerShell 7+) if present.
  2. Fall back to Git Bash — reuse the existing CLAUDE_CODE_GIT_BASH_PATH / isGitBashAvailable

detection the CLI/worktree code already has.

  1. Fall back to powershell.exe (5.1) only if nothing else is available.

And/or honor an explicit override (env var or managed setting) for the integrated terminal's
shell path, so policy-managed fleets can point it at an allowed interpreter.

Error Messages/Logs

[info] LocalSessions.startShellPty: sessionId=local_..., cols=162, rows=92
[info] [pty-host] Error: Cannot create process, error code: 1260
[info] [pty-host]     at WindowsPtyAgent._completePtyConnection (...node_modules\node-pty\lib\windowsPtyAgent.js:116:36)
[warn] [pty-host] worker exited (1) with 1 live PTY(s); refork on demand
[error] [pty-host] worker unusable; backing off before refork
[info] Shell PTY for session local_... exited with code 1260

---

Windows error 1260 = ERROR_ACCESS_DISABLED_BY_POLICY ("This program is blocked by Group Policy").

Steps to Reproduce

  1. On a Windows 11 machine, block Windows PowerShell 5.1 (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe)

via AppLocker/WDAC/Group Policy - as is standard on many managed enterprise fleets.
(PowerShell 7 pwsh.exe and Git Bash may be installed and on PATH; it makes no difference.)

  1. Open Claude Desktop for Windows.
  2. Open the integrated terminal (Code tab → terminal).
  3. Observe "Shell exited." Click "Restart Shell" - it fails identically.
  4. Confirm in %APPDATA%\Claude\logs\main.log: Shell PTY for session ... exited with code 1260.

<img width="606" height="761" alt="Image" src="https://github.com/user-attachments/assets/13d37871-d10b-4e60-8d03-1478e46e6707" />

Note: no setting changes the outcome, because the terminal shell is hardcoded to powershell.exe
(function L(){return{shell:"powershell.exe",args:[]}} in app.asar).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.211 (Claude Code); Claude Desktop ~1.22209.0 (MSIX build 2026-07-16)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Evidence gathered from the shipped MSIX (app/resources/app.asar, build 2026-07-16):

  • Hardcoded terminal shell resolver:

function L(){return{shell:"powershell.exe",args:[]}}
Local (non-SSH) spawn: const p = d ?? {...L(), cwd:a}; const u = v(p.shell, p.args, {...})
(v = node-pty spawn). No env/PATH/pwsh/git-bash detection on this path.

  • defaultShell setting explicitly does NOT apply -

its own schema description reads:
"Default shell for input-box ! commands. Defaults to 'bash' on all platforms (no Windows auto-flip)."

  • CLAUDE_CODE_GIT_BASH_PATH is honored only by the CLI Bash tool / git-worktree logic

(isGitBashAvailable), not by the terminal PTY.

  • Full managed-settings surface reviewed (every flatKey in the binary); none relate to

shell/terminal selection. Enterprise registry policies at HKLM\SOFTWARE\Policies\Claude
likewise expose no shell key.

Environment specifics on the affected machine:

  • pwsh 7.5.8 present at C:\Program Files\PowerShell\7\pwsh.exe (on PATH, works)
  • Git Bash present at C:\Program Files\Git\bin\bash.exe (works)
  • Windows PowerShell 5.1 blocked by policy (launching it returns access-denied / 1260)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗