[BUG] VS Code extension: "Could not locate the Claude CLI on PATH" false positive since v2.1.214 (regression from v2.1.212), likely related to where.exe output handling on Windows with non-ASCII username

Status Open
Reported on v2.1.214
Maintainer reply None cached
Activity 3 comments · opened Jul 22, 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 VS Code extension (Claude Code for VS Code) fails to launch with a "Could not locate the Claude CLI on PATH" error, even though the claude CLI is correctly installed and on PATH.

This appeared immediately after the VS Code extension auto-updated. Bisecting extension versions shows a clear regression boundary:

  • v2.1.212 and earlier: works correctly
  • v2.1.214 and later (confirmed on v2.1.214 and v2.1.217): fails with the error

Note: the underlying claude CLI binary itself auto-updates independently and was already at v2.1.217 even while the extension was pinned to v2.1.212 and working correctly. This indicates the bug is in the extension's own CLI-detection logic, not in the CLI binary.

Environment:

  • OS: Windows 11
  • Windows username contains non-ASCII (Japanese) characters, e.g. C:\Users\山田太郎\
  • Claude CLI installed via the standalone installer at C:\Users\<username>\.local\bin\claude.exe
  • VS Code extension: anthropic.claude-code, versions 2.1.214–2.1.217 reproduce the issue; 2.1.212 does not

Diagnostics already performed (all ruled out as the cause):

  1. User PATH persistence: confirmed .local\bin is correctly and persistently registered in the User PATH ([Environment]::GetEnvironmentVariable('PATH','User'))
  2. Get-Command claude from inside the VS Code integrated terminal correctly resolves to C:\Users\山田太郎\.local\bin\claude.exe (CommandType: Application)
  3. where.exe claude correctly returns C:\Users\山田太郎\.local\bin\claude.exe
  4. ASCII-only junction workaround: created a directory junction C:\ClaudeCLI.local\bin (no non-ASCII characters), added to PATH. where.exe /r C:\ClaudeCLI claude correctly resolves. VS Code was fully restarted. Error still occurred, suggesting the extension may be resolving/mangling the home directory path (which still contains non-ASCII characters) elsewhere before this check.
  5. No shadowing file: confirmed there is no file/folder named claude* in the open workspace root that could shadow the CLI via Windows' cwd-first executable search
  6. Clean reinstall: fully uninstalled the extension (including its .vscode\extensions\anthropic.claude-code-* folder) and reinstalled — issue persisted on the latest version
  7. Windows Defender: checked Microsoft-Windows-Windows Defender/Operational log for ASR block events (ID 1121) around the time of failure — none found

Suspected root cause:

The v2.1.214 changelog includes: "Fixed the PowerShell tool reporting where.exe, fc.exe, and diff.exe as errors when they return a valid negative answer (Windows)". This suggests the extension's internal handling of where.exe output/exit-code interpretation changed in this release. Combined with the non-ASCII (Japanese) Windows username in this environment, it's possible that:

  • the extension mishandles the encoding of where.exe's stdout on non-English Windows locales (e.g., reading a codepage-encoded buffer as UTF-8), producing a mangled/invalid path that then fails an existence check, and/or
  • the change to error-vs-negative-answer interpretation introduced a regression for this environment

Workaround: Pinning the VS Code extension to v2.1.212 (via "Install Another Version") resolves the issue. The CLI itself continues to auto-update normally; only the extension version needs to be pinned.

What Should Happen?

The extension should locate the correctly-installed and PATH-registered claude CLI without producing a false "not found" error, regardless of non-ASCII characters in the Windows username/profile path.

Error Messages/Logs

Failed to run Claude Code: Error: Could not locate the Claude CLI on PATH. Launching by name in a PowerShell terminal would run a 'claude' from the open folder instead of the installed CLI, so the launch was blocked. Make sure the Claude CLI's install directory is on your system PATH (not only your PowerShell profile), then restart VS Code and try again. VS Code reads PATH when it starts, so PATH changes take effect only after a restart.

Steps to Reproduce

  1. Install Claude Code CLI via the standalone installer (.local\bin\claude.exe) on a Windows account whose username contains non-ASCII characters
  2. Confirm the CLI works from a terminal: claude --version succeeds
  3. Install/update the "Claude Code for VS Code" extension to v2.1.214 or later
  4. Fully restart VS Code
  5. Try to open/run Claude Code from the extension
  6. Observe the "Could not locate the Claude CLI on PATH" error

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.212

Claude Code Version

2.1.217

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗

3 Comments

nishidate · 1 month ago

Update: I've narrowed down the root cause further. The v2.1.212 → v2.1.214 regression boundary I identified earlier still holds, but the bug is specifically confined to the claudeCode.useTerminal: true code path:

  • v2.1.212 with claudeCode.useTerminal: true: works correctly
  • v2.1.214–v2.1.217 with claudeCode.useTerminal: true: fails with the "Could not locate the Claude CLI on PATH" error
  • v2.1.217 with claudeCode.useTerminal: false (default/webview panel mode): works correctly

So something changed in v2.1.214 specifically within the useTerminal terminal-launch logic. The webview panel path is unaffected on the latest version.

This may be closely related to #78976 (claudeCode.useTerminal regression reports starting in v2.1.214).

Workaround for anyone hitting this: disable claudeCode.useTerminal in settings. You can then keep the extension on the latest version.

nishidate · 1 month ago

Update: Progress to report. Between v2.1.218 and v2.1.220 (I can't pinpoint which exact version, as v2.1.219/v2.1.220 release notes don't itemize this), something changed for the better:

  • ASCII-only path (junction workaround, e.g. C:\ClaudeCLI) + claudeCode.useTerminal: true:
  • v2.1.212–v2.1.218: fails
  • v2.1.220: now works correctly
  • Actual Windows home directory path with non-ASCII (Japanese) characters + claudeCode.useTerminal: true:
  • v2.1.212: works
  • v2.1.214–v2.1.220: still fails

So there's been a partial fix (possibly incidental) affecting the general PATH-detection logic, but the core issue — non-ASCII characters specifically in the path — remains unresolved as of v2.1.220.

majosaurus · 1 month ago

I'd like to report the same behaviour for Latin-script diacritics.

Environment:

  • OS: Windows 11
  • Username contains a diacritic (letter á)
  • CLI installed via standalone installer at C:\Users\username\.local\bin\claude.exe
  • Same error message, works in terminal, works in GUI panel, fails only in useTerminal-mode launch

_Copying_ the binary (_not_ linking it) to a path unrelated to %USERPROFILE% (e.g., C:\claude-bin\claude.exe) does work for me.