Skip to content

[Bug]: Claude provider fails on Windows when Claude Code is installed globally with pnpm #24293

New issue
New issue
Open
#24533
Open
[Bug]: Claude provider fails on Windows when Claude Code is installed globally with pnpm#24293
#24533
Labels
bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

Description

@Neonsy
Neonsy
opened on Oct 24, 2026

Before submitting

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

Area

apps/server

Steps to reproduce

  1. On Windows, install Claude Code globally with pnpm instead of the official installer: pnpm add -g --allow-build=@anthropic-ai/claude-code @anthropic-ai/claude-code
  2. Confirm pnpm's global bin directory is on PATH and that claude --version and claude auth status work in a terminal
  3. Leave the Claude provider's Binary path at the default claude
  4. Start T3 Code and open Settings → Providers → Claude, or start a Claude thread

Expected behavior

T3 Code finds the real claude.exe behind pnpm's claude.cmd launcher, as it already does for npm's layout. The account status check and Claude turns work

Actual behavior

The Claude provider shows "Needs attention · Claude Agent CLI failed while checking account status"

The claude --version check passes, because it runs through resolveSpawnCommand, which can start .cmd launchers through a shell. The Agent SDK cannot start launcher scripts, so resolveClaudeSdkExecutablePath in apps/server/src/provider/Drivers/ClaudeExecutable.ts looks for the real executable. It only checks npm's layout next to the launcher, node_modules/@anthropic-ai/claude-code/bin/claude.exe and cli.js. With pnpm it finds neither, logs a warning, and passes the bare claude name to the SDK, which cannot start it. The capability probe then fails with UnknownError

pnpm's launcher points to a different folder:

@SETLOCAL
@"%~dp0\..\global\v11\<hash>\node_modules\@anthropic-ai\claude-code\bin\claude.exe"  %*

The V2 adapter calls the same resolver, so Claude turns fail too, not only the status card. The official PowerShell installer works because it installs a real claude.exe, which the resolver returns unchanged. Codex installed with pnpm add -g @openai/codex also works, because T3 starts it through resolveSpawnCommand

Related:

Suggested fix: Revive the approach from #5678. Read the target path from the .cmd, .ps1, or sh launcher, relative to %~dp0 or $basedir, and use it when it points to an existing claude.exe or cli.js. T3 already detects pnpm global installs for provider updates in packages/provider-core/src/server/maintenanceResolver.ts

Impact

Major degradation or frequent failure

Version or commit

0.1.3-nightly.20261023.3592 (e340aae), resolver unchanged on main @ 6c21798

Environment

Windows 10 (22H2), T3 Code desktop nightly, Claude Code 2.1.310 installed globally with pnpm 12, Node 24

Logs or stack traces

[WARN] resolveClaudeSdkExecutablePath
Claude launcher shim resolved but no known package entry was found next to it; the Claude Agent SDK cannot spawn launcher scripts directly.
{ "binaryPath": "claude", "resolvedShimPath": "<pnpm-bin-dir>\\claude.CMD" }

[WARN] checkClaudeProviderStatus
Claude capability probe failed. { "errorTag": "UnknownError" }

(runClaudeCommand for `claude --version` succeeded in the same check)

Screenshots, recordings, or supporting files

No response

Workaround

Set the Claude provider's Binary path to the real executable that pnpm's launcher points to: <pnpm-home>\global\v11\<hash>\node_modules\@anthropic-ai\claude-code\bin\claude.exe

The exact path is inside <pnpm-bin-dir>\claude.cmd. The <hash> folder changes when Claude Code is reinstalled or upgraded, so the path must be updated each time

Activity

  1. Neonsy
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Oct 24, 2026

  2. Neonsy commented on Oct 24, 2026

    @Neonsy
    Neonsy
    on Oct 24, 2026
    Author

    Pinging @juliusmarminge because no triage has happened so far

  3. Ciatel-Arlanta commented on Oct 24, 2026

    @Ciatel-Arlanta
    Ciatel-Arlanta
    on Oct 24, 2026

    Reproduced on Windows 11 (build 26300) against current main (d53873b6a), with Claude Code 2.1.309 installed globally by pnpm 11.18 into an isolated PNPM_HOME.

    pnpm writes the launcher to <PNPM_HOME>\bin\claude.CMD:

    @SETLOCAL
@"%~dp0\..\global\v11\7674-1a16f3bff9d-6efed413fb25d243\node_modules\@anthropic-ai\claude-code\bin\claude.exe"   %*

    Running the real resolveClaudeSdkExecutablePath("claude", env), with only that bin directory on PATH, finds claude.CMD, logs the warning from the report, and returns the bare claude:

    WARN: Claude launcher shim resolved but no known package entry was found next to it; ...
  { binaryPath: 'claude', resolvedShimPath: '...\pnpm-home\bin\claude.CMD' }
resolved = claude

    What the SDK gets for each candidate when it spawns without a shell, same PATH:

    Spawned Result
    claude ENOENT (the SDK reports "native binary not found")
    ...\bin\claude.CMD EINVAL
    ...\global\v11\<hash>\node_modules\@anthropic-ai\claude-code\bin\claude.exe 2.1.309 (Claude Code)

    The shared npmShimExecutable in packages/shared/src/shell.ts returns undefined for this launcher too, because it only accepts npm's exact shim.

    The cause is as described: the resolver only checks npm's fixed layout next to the launcher, and pnpm keeps the package under a hash directory that changes on every install or upgrade. The pnpm layout #5678 targeted (global\5\.pnpm\...) is also gone in pnpm 11+.

    I'll open a focused PR. It reads only pnpm's exact .cmd form, resolves the target against the launcher's directory, and accepts it only if it is the Claude Code claude.exe and exists, with a regression test in ClaudeExecutable.test.ts.

  4. sasensi commented on Oct 30, 2026

    @sasensi
    sasensi
    on Oct 30, 2026

    Confirmed another launcher layout affected by the same resolver limitation.

    Environment: T3 Code desktop/local server 0.1.5; Windows 11 x64, build 26200; Claude Code 2.1.283.

    With Binary path set to claude, it resolves to:

    %LOCALAPPDATA%\Microsoft\WinGet\Links\claude.cmd

    That launcher contains:

    @echo off
"%LOCALAPPDATA%\Microsoft\WinGet\Packages\Anthropic.ClaudeCode_Microsoft.Winget.Source_8wekyb3d8bbwe\claude.exe" %*

    claude --version and claude auth status succeed in PowerShell; authentication is valid. T3 logs:

    Claude launcher shim resolved but no known package entry was found next to it; the Claude Agent SDK cannot spawn launcher scripts directly.
Claude capability probe failed. { "errorTag": "UnknownError" }

    Direct Node spawning without a shell reproduces:

    • claude → ENOENT
    • Absolute claude.cmd path → EINVAL
    • Underlying claude.exe → exit 0, version 2.1.283

    Setting T3’s Binary path to that underlying executable resolved the provider warning; the user confirmed success.

    The v0.1.5 resolver checks only npm package entries beside the launcher. PR #24533 appears specific to pnpm’s launcher format, so this layout may need separate coverage.

    Investigated by GPT-6.1 Sol via Codex in T3 Code, using the t3 triage playbook.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions