[BUG] /ide says "No available IDEs detected" while listing a running IDE; no debug output explains the cwd/workspace mismatch

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Jul 31, 2026

What's Wrong?

When /ide rejects an IDE because its workspace does not contain the session cwd, the panel opens with a line that is factually false and actively misdirects, then contradicts itself on the very next line:

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

Found 1 other running IDE(s). However, their workspace/project directories
do not match the current cwd.

   ● Visual Studio Code - Insiders: Claude/from_scratch

The extension is installed and is running, and Claude Code demonstrably knows this — it lists the IDE, resolves its workspace, and even renders the path (Claude/from_scratch) relative to the cwd, proving it computed the containment relationship. Yet the headline sends the user off to verify an extension install that was never the problem.

Compounding it: /ide emits zero debug output, even with debug logging enabled. Across a 375-line debug log, the entire /ide invocation appears as one UI line (repinScroll(onSubmit, ...)) and nothing else — no lock files scanned, no workspaceFolders parsed, no cwd comparison, no accept/reject reason. There are 0 [ERROR] and 0 [WARN] entries. Diagnosing this required manually reading ~/.claude/ide/*.lock and checking listening ports, because the tool reports nothing about a decision it just made.

Steps to Reproduce

  1. Open a folder in VS Code with the Claude Code extension, e.g. ~/Claude/from_scratch
  2. Launch claude from a parent directory (cd ~ && claude)
  3. Run /ide

The IDE is correctly excluded (its workspace is a child of cwd, not an ancestor), but the message blames the extension.

What Should Happen?

  1. Lead with the actual cause. When at least one IDE was discovered, do not print "No available IDEs detected" or advise checking the extension install. Say the workspace doesn't cover the session directory and print both paths concretely:

``
Found 1 running IDE, but none covers the current directory.
● Visual Studio Code - Insiders
workspace: /Users/xiang/Claude/from_scratch
cwd: /Users/xiang
Restart Claude Code from inside the workspace, or open a folder
containing the cwd in your IDE.
``

Reserve the "check the extension is installed and running" wording for a genuinely empty discovery result.

  1. Log the decision under --debug. Lock files found, workspaceFolders parsed from each, the cwd compared against them, and the accept/reject reason per IDE.

Environment

  • Claude Code 2.1.220 (native install)
  • macOS Darwin 25.5.0, arm64
  • Terminal: Apple Terminal (not the integrated terminal)
  • VS Code Insiders 1.132.0-insider, extension anthropic.claude-code 2.1.220-darwin-arm64
  • Lock file present and valid, extension server listening (authToken redacted):

``json
{"pid":66832,
"workspaceFolders":["/Users/xiang/Claude/from_scratch"],
"ideName":"Visual Studio Code - Insiders",
"transport":"ws","runningInWindows":false,
"authToken":"<redacted>"}
``

Notes

This is about the messaging and diagnostics, not the matching rule — requiring the workspace to contain the cwd is reasonable, since an IDE rooted at a subdirectory cannot open or diff files elsewhere in the session scope.

Related: #61165 requested the behavioral change (allow a workspace that is a subfolder of cwd). It was auto-closed as a duplicate of #50192, but #50192 is a different bug (connecting to the wrong IDE instance among several) and was itself closed as stale. The subfolder case was never actually triaged. Both are locked, so this is filed fresh rather than as a comment.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗