Skip to content
Source
Sign inSign up

pingdotgg

t3codePublic Synced with GitHub
Popular #1 Fork 0

[Bug]: Windows: Claude "Install" fails when PowerShell is blocked by group policy (no install.cmd fallback) #35141

Send to my agent
ClosedGoomal(GitHub profile, opens in a new tab) opened this issue 2 comments
Goomal(GitHub profile, opens in a new tab)commented

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Use a Windows 11 machine where powershell.exe is blocked by group policy (running it shows "This program is blocked by group policy") and pwsh.exe is not installed.
  2. Install T3 Code (Beta) 0.1.9 and launch it for the first time.
  3. On the "Welcome to T3 Code" screen, under Agents > Set up an agent, click "Install" next to Claude.
  4. A panel opens showing "Could not open the setup terminal." with Retry / Close.
  5. Click Retry: it fails the same way every time. Claude stays "not installed".

Expected behavior

Clicking "Install" next to Claude should install Claude Code even when PowerShell is blocked, for example by falling back to Anthropic's CMD installer (https://claude.ai/install.cmd) through cmd.exe.

If the setup terminal can't open, T3 Code should say why (e.g. "PowerShell is unavailable or blocked by policy") and offer an alternative: the cmd.exe install command, or a field to set Claude's Binary path.

After Claude Code is installed with the official installer, T3 Code should also find claude.exe in the installer's default location (%USERPROFILE%.local\bin or %HOME%.local\bin), even when that folder isn't on PATH.

Actual behavior

Clicking "Install" next to Claude opens a panel that only says "Could not open the setup terminal." with Retry / Close. Retry fails the same way every time, no reason is shown, and Claude stays "not installed".

The T3 Code logs show:

  • DesktopShellEnvironmentCommandError: Desktop shell environment powershell-no-profile probe (pwsh.exe) failed (NotFound)
  • The Claude health check keeps failing: PlatformError: NotFound: ChildProcess.spawn (claude --version) / spawn claude ENOENT
  • The provider cache reports: "Claude Agent CLI (claude) was not found on PATH." with "canInstall": false

After installing Claude Code manually with install.cmd from cmd.exe, claude.exe lands in %HOME%.local\bin (a mapped network drive on this machine), which isn't on PATH. Registry editing is disabled by policy, so the folder can't easily be added to PATH, and T3 Code still reports "not found on PATH" until Settings > Providers > Claude > Binary path is set by hand.

Impact

Blocks work completely

Version or commit

T3 Code (Beta) 0.1.9 (Windows desktop release, installed via the GitHub release installer)

Environment

  • OS: Windows 11 Pro 10.0.26200 (x64), domain-joined / managed by group policy - App: T3 Code (Beta) 0.1.9 desktop app - powershell.exe blocked by group policy; pwsh.exe (PowerShell 7) not installed - Registry editing disabled by policy - HOME points to a mapped network drive (U:), not %USERPROFILE% - Network blocks certificate revocation checks (curl/schannel fails with CRYPT_E_NO_REVOCATION_CHECK unless --ssl-revoke-best-effort is used) - Node/Bun: not installed on the system - Provider: Claude (Claude Code 2.1.322, installed manually via install.cmd)

Logs or stack traces

# desktop.trace.ndjson — shell environment probe at startup
DesktopShellEnvironmentCommandError: Desktop shell environment powershell-no-profile probe (pwsh.exe) failed.
  cause: { _tag: "NotFound", module: "ChildProcess", method: "spawn", pathOrDescriptor: "pwsh.exe -NoLogo ..." }
(same failure for the powershell-profile probe)

# server-child.log — repeated on every provider refresh
WARN: Claude Agent CLI health check failed.
  { errorTag: 'PlatformError' }

# server.trace.ndjson — checkClaudeProviderStatus
PlatformError: NotFound: ChildProcess.spawn (claude --version)
    at systemError (file:///C:/Users/<user>/AppData/Local/Programs/t3code/resources/server.asar/apps/server/dist/ManagedEndpointRuntime-B-62Mn5X.mjs:7429:34)
    at runClaudeCommand (.../server.asar/apps/server/dist/runtimeLayer-BR0FRrjb.mjs:55052:30)
    at checkClaudeProviderStatus (.../server.asar/apps/server/dist/runtimeLayer-BR0FRrjb.mjs:55366:112)
  [cause]: Error: spawn claude ENOENT

# ~/.t3/caches/claudeAgent.json
"installed": false,
"status": "error",
"setup": { "canAuthenticate": false, "canInstall": false },
"message": "Claude Agent CLI (`claude`) was not found on PATH."

# Running powershell.exe on this machine
This program is blocked by group policy. For more information, contact your system administrator.

Screenshots, recordings, or supporting files

צילום מסך 2026-11-12 112605.png

Workaround

No response

  1. Goomal(GitHub profile, opens in a new tab) added labelsbug

  2. Goomal(GitHub profile, opens in a new tab) added labelsneeds-triage

  3. juliusmarmingecommented

    I tried to reproduce this on the current build and could not.

    No worker has a Windows host with powershell.exe blocked by group policy, so the desktop flow could not be run for real. On origin/main 56c4e20fff I traced the Install button: WelcomePage opens a PTY through TerminalManager.open, whose Windows shell list is pwsh.exe -> %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe -> powershell.exe -> %ComSpec% -> cmd.exe, and trySpawn moves to the next shell only when isRetryableShellSpawnError finds 'enoent'/'not found'/'posix_spawnp failed' in the error. A policy-blocked CreateProcess reports through node-pty's ConPTY as 'Cannot create process, error code: 1260' (ERROR_ACCESS_DISABLED_BY_POLICY), which is not retryable, so open fails at built-in PowerShell and the UI shows 'Could not open the setup terminal.' on every retry. I added the test 'falls back to cmd when group policy blocks PowerShell on Windows' to apps/server/src/terminal/Manager.test.ts (FakePtyAdapter failures: 'File not found: pwsh.exe', then error code 1260 twice). vp test run apps/server/src/terminal/Manager.test.ts -t "group policy" fails on main: the last shell spawned is C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, expected C:\Windows\System32\cmd.exe. The exact node-pty error text for a policy block is an assumption from its conpty.cc formatting.

    Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.

  4. juliusmarminge closed this

  5. Goomal(GitHub profile, opens in a new tab)commented

    Thanks for digging into this. I think your trace actually confirms the bug rather than ruling it out.

    Your new test "falls back to cmd when group policy blocks PowerShell on Windows" fails on main 56c4e20: after pwsh.exe is not found, built-in PowerShell fails with error 1260 (ERROR_ACCESS_DISABLED_BY_POLICY), isRetryableShellSpawnError doesn't treat that as retryable, and %ComSpec% / cmd.exe is never tried. That matches exactly what I see.

    On the one assumption you flagged: on my machine, running powershell.exe gives "This program is blocked by group policy. For more information, contact your system administrator.", which is the system message for error 1260. So a policy-blocked spawn really is reporting 1260 here.

    Details again:

    • Version: T3 Code (Beta) 0.1.9, Windows 11 Pro 10.0.26200, domain-managed
    • powershell.exe blocked by group policy, pwsh.exe not installed
    • Steps: first launch -> Welcome screen -> Set up an agent -> "Install" next to Claude -> "Could not open the setup terminal." Retry fails the same way every time.

    Could you reopen this? Treating error 1260 (or any non-ENOENT spawn failure) as retryable so it falls through to cmd.exe would fix it, and your test already covers it. I'm happy to test a build on this machine.

Sign in to join this conversation.