[BUG] VSCode integrated terminal cannot detect 'code' command - IDE connection fails (Windows)

[elfenlieds7]

Bug Description

When running Claude Code from VSCode's integrated terminal on Windows, the IDE detection fails with error:

'code' is not recognized as an internal or external command, operable program or batch file.

However, running Claude Code from an external terminal (Windows Terminal/CMD) works correctly and can detect/connect to VSCode.

Environment

• Claude Code version: 2.0.62
• OS: Windows 11
• VSCode version: 1.106.3
• Terminal: VSCode integrated terminal (PowerShell/bash)
• Claude Code Extension: anthropic.claude-code (installed and enabled)

Steps to Reproduce

1. Open VSCode with a project folder
2. Open VSCode's integrated terminal
3. Run claude
4. Run /ide or check Status page

Expected: IDE should be detected and connected Actual: Error message "'code' is not recognized as an internal or external command"

Workaround

Running Claude Code from an external Windows Terminal works:

cd C:\path\to\project
claude
/ide  # Successfully detects VSCode

Additional Context

• The code command works fine when run directly in the same VSCode integrated terminal
• The VSCode extension is properly installed and functional
• This appears to be a regression - similar issue was reported in #3492 (for version 1.0.51) but marked as closed
• The IDE lock file at ~/.claude/ide/*.lock shows correct VSCode detection when connected from external terminal

Diagnostic Info

From /status in VSCode integrated terminal:

IDE: ✘ Error installing VS Code extension: 1: 1 'code' is not recognized as an internal or external command,
      operable program or batch file.
      Please restart your IDE and try again.

From external terminal (working):

IDE lock file content:
{"pid":12484,"workspaceFolders":["c:\Users\..."],"ideName":"Visual Studio Code","transport":"ws","runningInWindows":true,"authToken":"..."}

🤖 Generated with Claude Code

[github-actions[bot]]

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/5153
2. https://github.com/anthropics/claude-code/issues/3492
3. https://github.com/anthropics/claude-code/issues/12470

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[elfenlieds7]

Root Cause Found! 🎯

After debugging, we found the exact issue:

VS Code bin directory contains two different files:

C:\Program Files\Microsoft VS Code\bin\
├── code      # Shell script (#!/usr/bin/env sh) - for bash/WSL
├── code.cmd  # Windows batch file - for cmd.exe
└── code-tunnel.exe

The Problem:

When Claude Code tries to run code --install-extension on Windows:

• If it spawns via cmd.exe but somehow invokes code (the shell script) instead of code.cmd, it fails
• cmd.exe cannot execute shell scripts

Test Results:

Command	Result
cmd.exe /c "code --version"	❌ Hangs/Timeout
cmd.exe /c "code.cmd --version"	✅ Works
powershell.exe -Command "code --version"	✅ Works
Bash: code --version	✅ Works (uses shell script)

Suggested Fix:

Claude Code should explicitly use code.cmd instead of code when running on Windows, or use PowerShell instead of cmd.exe for spawning the command.

Environment Details:

• Windows 11
• VS Code 1.106.3
• Claude Code 2.0.62
• Running from VSCode integrated terminal (Git Bash)

🤖 Generated with Claude Code

[elfenlieds7]

Additional Finding: Claude Code hardcodes cmd.exe syntax (/d /s /c flags). When COMSPEC is changed to PowerShell, it still uses cmd.exe syntax which PowerShell cannot parse. This confirms the bug is in Claude Code's shell handling on Windows.

[elfenlieds7]

Additional Issue: Workspace Folder Matching Doesn't Support Subfolders

After resolving the code command issue (using CLAUDE_CODE_AUTO_CONNECT_IDE=false and manual extension installation), we discovered another related problem:

Problem

The IDE detection workspace folder matching logic doesn't support subfolders.

For example:

• VSCode has folder C:\Users\user\projects open
• Claude Code CLI runs in C:\Users\user\projects\my-app
• Expected: CLI should connect to VSCode (since cwd is a subfolder of workspace)
• Actual: "No available IDEs detected" - CLI fails to match

The lock file shows:

{"workspaceFolders":["c:\Users\user\projects"], ...}

But the CLI running in the my-app subfolder cannot connect.

Workaround

Open the specific subfolder directly in VSCode (not the parent), so the workspace folder exactly matches the CLI's cwd.

Impact

This breaks a common workflow:

1. Open parent folder containing multiple related repos (e.g., backend/, frontend/, shared/)
2. Run multiple Claude Code instances in different subfolders
3. All should connect to the same VSCode instance

Currently, users must either:

• Open multiple VSCode windows (one per repo)
• Use multi-root workspaces with each subfolder explicitly added

Suggestion

The matching logic should check if the CLI's cwd is a subfolder of any workspace folder, not just an exact match.

🤖 Generated with Claude Code

[elfenlieds7]

Update: Found Root Cause - Case-Sensitive Path Comparison on Windows

After further testing with multi-root workspaces, we identified the root cause of the workspace matching failure:

The Bug

The IDE lock file stores paths with lowercase drive letter:

"workspaceFolders":["c:\Users\songym\cursor-projects\nexus-frontend", ...]

But the CLI's cwd uses uppercase drive letter:

cwd: C:\Users\songym\cursor-projects\nexus-frontend

The matching logic appears to do a case-sensitive string comparison, causing c:\... ≠ C:\... even though they're the same path on Windows.

Impact

This affects ALL Windows users using multi-root workspaces (and likely single-folder workspaces too, depending on how the path is resolved).

Expected Behavior

On Windows, path comparison should be case-insensitive, or paths should be normalized to the same case before comparison.

Suggested Fix

// Before comparison, normalize paths on Windows:
if (process.platform === 'win32') {
  cwd = cwd.toLowerCase();
  workspaceFolders = workspaceFolders.map(f => f.toLowerCase());
}

🤖 Generated with Claude Code

[elfenlieds7]

Update: Auto-install Failure Blocks Lock File Fallback

Found another issue in the IDE connection flow:

Problem

When CLAUDE_CODE_AUTO_CONNECT_IDE=true (default):

1. Claude Code tries to auto-install extension via code --install-extension
2. On Windows, this fails with "'code' is not recognized..."
3. The failure blocks the entire IDE connection flow - it doesn't fallback to lock file discovery

When CLAUDE_CODE_AUTO_CONNECT_IDE=false:

1. Skips auto-install
2. Directly uses lock file discovery
3. ✅ Successfully connects to IDE

Expected Behavior

Even if auto-install fails, Claude Code should gracefully fallback to trying lock file-based IDE discovery.

Workaround

Set environment variable permanently:

[Environment]::SetEnvironmentVariable('CLAUDE_CODE_AUTO_CONNECT_IDE', 'false', 'User')

Then restart all Claude Code sessions.

🤖 Generated with Claude Code

[elfenlieds7]

Update: Workaround Found - Python venv Activation Fixes the Issue

After extensive debugging, we found a surprising workaround:

The Problem

In a VSCode multi-root workspace, Claude Code fails to detect IDE in some folders but works in others:

• Terminal opened in nexus/ folder → IDE connection works ✅
• Terminal opened in nexus-frontend/ folder → "Error installing VS Code extension: 'code' is not recognized" ❌

Both terminals have:

• Same CLAUDE_CODE_AUTO_CONNECT_IDE=false environment variable
• Same PATH containing C:\Program Files\Microsoft VS Code\bin
• code --version works in both terminals

Key Discovery

The difference: the nexus/ folder has a Python venv that auto-activates.

Workaround

Activating ANY Python venv before running Claude Code fixes the issue:

# In the problematic terminal, activate a venv first:
& C:\path\to\any\.venv\Scripts\Activate.ps1

# Then run Claude Code - it works!
claude

Analysis

The venv activation script (Activate.ps1) does two things:

1. Prepends venv's Scripts/ directory to PATH
2. Sets VIRTUAL_ENV and VIRTUAL_ENV_PROMPT environment variables

Somehow this affects how Claude Code spawns cmd.exe subprocesses to run the code command. Even though code --version works directly in both terminals, Claude Code's internal subprocess execution only works after venv activation.

Hypothesis

This might be related to how PowerShell passes environment variables to cmd.exe /d /s /c subprocesses. The venv activation might be changing some shell state that affects child process environment inheritance.

VSCode Terminal Profile Workaround

Users can add venv activation to their VSCode terminal profile to auto-fix this:

// settings.json
"terminal.integrated.profiles.windows": {
    "PowerShell (with venv)": {
        "source": "PowerShell",
        "args": ["-NoExit", "-Command", "& 'C:\path\to\venv\Scripts\Activate.ps1'"]
    }
}

🤖 Generated with Claude Code

[elfenlieds7]

Critical Finding: The Problem is Claude Code's Subprocess Handling

We've isolated the issue further:

Test Results

In the same terminal where Claude Code fails with "'code' is not recognized":

# This works fine:
PS> cmd.exe /c 'code --version'
1.106.3
bf9252a2fb45be6893dd8870c0bf37e2e1766d61
x64

# But Claude Code fails when trying to run the same command internally

Conclusion

The code command IS accessible via cmd.exe in the terminal environment. The PATH is correct. The problem is specifically in how Claude Code spawns its subprocess - it's not inheriting or passing the PATH environment variable correctly.

This is NOT a terminal environment issue - it's a Claude Code internal bug in subprocess handling on Windows.

Additional Data Points

1. Activating a Python venv before running Claude Code somehow works around this issue
2. The venv activation modifies PATH and sets VIRTUAL_ENV/VIRTUAL_ENV_PROMPT
3. Even after removing the venv entirely, the issue persists
4. The issue affects Claude Code 2.0.62 on Windows 11 with VSCode 1.106.3

🤖 Generated with Claude Code

[github-actions[bot]]

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.