Skip to content

Conversation

@agrasth
Copy link
Collaborator

@agrasth agrasth commented Oct 29, 2025

  • All tests passed. If this feature is not already covered by the tests, I added new tests.
  • All static analysis checks passed.
  • Appropriate label is added to auto generate release notes.
  • I used gofmt for formatting the code before submitting the pull request.
  • PR description is clear and concise, and it includes the proposed solution/fix.

Fix Windows IDE Detection for VSCode, Cursor, and Windsurf

Problem

IDE detection failed on Windows with error: "installation not found in standard locations"

Solution

  • Use os.Getenv() to manually expand Windows environment variables
  • Added comprehensive Windows paths (5 for VSCode, 4 for Cursor/Windsurf)
  • Added Linux snap and vscode-server paths with glob support
  • Simplified error messages

Changes

Files Modified:

  • vscode_fork.go - Fixed environment variable expansion, added glob support
  • vscode_fork_registry.go - Added Windows and Linux detection paths
  • instructions.go - Simplified error messages

- Added 5 detection paths for VSCode (previously 2)
- Added 4 detection paths for Cursor (previously 2)
- Added 4 detection paths for Windsurf (previously 2)
- Improved error messages with Windows-specific instructions
- Fixed issue where IDEs installed in non-standard locations were not detected

This fixes the 'installation not found' error reported by Windows users.
Use os.Getenv() to manually expand Windows environment variables
instead of relying on os.ExpandEnv() which can be unreliable with
%VAR% syntax on Windows systems.

This matches the approach from the original working implementation
and should fix the 'installation not found' error on Windows.
Changed debug logs to info logs for easier visibility without -v flag.
This will help diagnose why IDE detection is failing on Windows by showing:
- All paths being checked
- Environment variable values (LOCALAPPDATA, PROGRAMFILES, etc.)
- Expanded paths after variable substitution
- Whether each path exists or not
Removed temporary debug/info logging that was used to diagnose
the Windows path detection issue. The core fix (using os.Getenv()
for Windows environment variables) is working correctly.

Tested and verified on Windows - Cursor detection successful.
Shortened manual setup and permission error messages since auto-detection
now works correctly. These are rare fallback messages so keeping them brief.
Added missing Linux detection paths from original implementation:
- Snap install path: /snap/code/current/usr/share/code/resources/app
- VSCode Server path: ~/.vscode-server/bin/*/resources/app (with glob support)

Also added glob pattern support in detectInstallation() to handle
wildcard paths like vscode-server installations.
@agrasth agrasth requested review from bhanurp and reshmifrog October 29, 2025 21:03
@agrasth agrasth added the bug Something isn't working label Oct 29, 2025
@agrasth agrasth changed the title Windows ide path fix Fix Windows IDE Detection Oct 29, 2025
- Updated setup.go with comprehensive description including all supported IDEs
- Added practical examples for VSCode, Cursor, and direct URL usage
- Removed unused setup/help.go file (was shadowed by setup.go)

The help now clearly shows all supported IDEs (vscode, cursor, windsurf, jetbrains)
with example commands for each.
Moved from:
  ide/docs/setup.go (package docs)

To:
  ide/docs/setup/help.go (package setup)

This matches the pattern used throughout the repo:
  - docs/<command-name>/help.go
  - package <command-name>

Updated import in cli.go from 'ide/docs' to 'ide/docs/setup'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant