Claude Code “No IDE Detected” — 5 Tested Fixes

Overview

Running /ide or launching Claude Code with the --ide flag and getting “No available IDEs detected”? The CLI needs a WebSocket connection to your editor’s Claude Code extension — if anything breaks that link, you get this error.

This guide covers five verified fixes targeting the most common root causes: missing extensions, WSL2 network isolation, Windows Firewall rules, manual installs for VS Code forks, and config directory issues. Each fix includes exact commands you can copy-paste.

What Causes This Error

Claude Code’s IDE detection runs a ps aux scan looking for specific process names: Visual Studio Code, Code Helper, Cursor Helper, Windsurf Helper, IntelliJ IDEA, PyCharm. When it finds a match, it attempts WebSocket connections on ports in the 42000–44000 range to reach the IDE extension’s server.

The detection fails when:

• The Claude Code extension or plugin isn’t installed in the IDE
• The IDE isn’t running, or the extension hasn’t started its WebSocket server
• Network isolation (WSL2 NAT) blocks the connection between CLI and IDE
• Windows Firewall drops the internal TCP traffic
• A custom CLAUDE_CONFIG_DIR breaks the detection logic

The exact error message:

No available IDEs detected. Make sure your IDE has the Claude Code
extension or plugin installed and is running.

Solution 1: Install the Claude Code Extension or Plugin

This fixes the majority of cases. Without the extension running inside your IDE, there’s no WebSocket server for the CLI to connect to.

VS Code:

Open the Extensions panel (Ctrl + Shift + X) and search for “Claude Code.” Install the extension published by Anthropic, then reload the window.

JetBrains IDEs (IntelliJ, PyCharm, WebStorm, GoLand, PhpStorm, Android Studio):

Go to Settings → Plugins → Marketplace, search “Claude Code,” and install the plugin. Restart the IDE.

After installing, verify it’s active:

Solution 2: Fix WSL2 Network Isolation

This is the most common cause for Windows users running Claude Code inside WSL2 while their IDE runs on the Windows host. WSL2 uses NAT networking by default, which prevents the CLI from reaching the IDE extension’s WebSocket server.

Option A — Switch to mirrored networking (recommended):

Create or edit %USERPROFILE%\.wslconfig on the Windows side:

[wsl2]
networkingMode=mirrored

Then restart WSL:

wsl --shutdown

Reopen your WSL terminal and run claude. The CLI can now reach the IDE’s WebSocket server through the mirrored network stack.

Option B — Add a firewall rule:

If mirrored networking isn’t an option, allow traffic between WSL2 and Windows on the relevant ports. Run this in an Administrator PowerShell:

# Find your WSL2 subnet
wsl hostname -I

# Create the inbound rule (adjust the subnet if yours differs)
New-NetFirewallRule -DisplayName "Allow WSL2 Internal Traffic" `
  -Direction Inbound -Protocol TCP -Action Allow `
  -RemoteAddress 172.21.0.0/16 -LocalAddress 172.21.0.0/16

Solution 3: Manual VSIX Install for Cursor and Windsurf

Claude Code detects Cursor and Windsurf via their helper processes, but it doesn’t auto-install its extension into these VS Code forks. You need to install the bundled VSIX file manually.

First, locate the VSIX:

# Find the Claude Code installation path
npm list -g --depth 0

# The VSIX lives at:
# <global_node_modules>/@anthropic-ai/claude-code/vendor/claude-code.vsix

On macOS with Homebrew, the typical path is:

/opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/vendor/claude-code.vsix

Install via CLI:

# For Cursor
cursor --install-extension /path/to/claude-code.vsix

# For Windsurf
windsurf --install-extension /path/to/claude-code.vsix

Install via UI: Open the Extensions panel in Cursor or Windsurf, click the ... menu at the top, select Install from VSIX…, and navigate to the file.

After installing, restart the editor and run /ide in Claude Code.

Solution 4: Fix JetBrains Detection on WSL

JetBrains IDEs on WSL had a specific detection bug that was resolved in Claude Code plugin version 0.1.6-beta. Update the plugin to the latest version through Settings → Plugins → Installed → Claude Code → Update.

If the problem persists after updating:

1. Open the project from Windows (not from inside WSL)
2. Open the IDE’s integrated terminal
3. Start WSL from that terminal: wsl -d Ubuntu
4. Navigate to your project directory
5. Run claude

This ensures the IDE process and Claude Code CLI share a network context. Combined with the WSL2 networking fix from Solution 2, this resolves virtually all JetBrains-on-WSL detection issues.

Solution 5: Check CLAUDE_CONFIG_DIR

If you’ve set the CLAUDE_CONFIG_DIR environment variable to a non-default path, IDE detection can break. This is a known issue (tracked in GitHub issue anthropics/claude-code#4739).

Check if it’s set:

echo $CLAUDE_CONFIG_DIR

If it returns a custom path, try unsetting it temporarily:

unset CLAUDE_CONFIG_DIR
claude

If /ide works after unsetting, you have two options:

• Remove the custom config directory setting permanently
• Wait for an upstream fix — the issue is tracked and acknowledged

Still Not Working?

If none of the above fixes resolve the issue:

1. Run /doctor inside Claude Code — it checks installation health, search functionality, MCP servers, and settings validity
2. Check the official troubleshooting docs for platform-specific guidance
3. Search Claude Code GitHub Issues for your specific IDE + OS combination
4. Open a new issue with the output of /doctor and your OS/IDE versions — the team is actively triaging IDE detection reports

You can also bypass IDE detection entirely and use Claude Code as a standalone CLI. The --ide auto-connect is a convenience feature, not a requirement. Claude Code works fully from any terminal.

FAQ