IDE forks break if CLI package is not installed

[thejackshelton]

In guess.js, the detection logic assumes that if an editor app is running, its CLI is available:

// Find editor by exact match.
if (processList.includes(processName)) {
  return [COMMON_EDITORS_MACOS[processName]]  // ← Returns 'cursor' without verification
}

In the case of many VSCode forks, such as Cursor IDE or Windsurf, the consumer may not have their CLI installed, instead using the VSCode command that they are used to.

Steps to Reproduce

1. Install Cursor IDE app (but don't install the CLI command)
2. Have Cursor app running
3. Use launch-editor (e.g., through Vite dev server's /__open-in-editor endpoint)
4. guessEditor detects Cursor process and returns ['cursor']
5. childProcess.spawn('cursor', ...) fails with ENOENT: spawn cursor ENOENT
6. Error shown to user with no fallback to VS Code or other available editors

Could not open index.tsx in the editor.
The editor process exited with an error: spawn cursor ENOENT ('cursor' command does not exist in 'PATH').

Proposed Solution

Add CLI verification and fall back to common editors when detected ones fail:

// Try detected running editors first
if (processList.includes(processName)) {
  const editorBin = COMMON_EDITORS_MACOS[processName]
  // check if CLI is installed, alternatively, check if it's a fork somehow?
}

// use fallback if CLI is not installed

Questions

1. Would you accept a PR for this fix? I'd be happy to look into it.
2. Are there existing test conventions I should follow?

Workaround

Users can set LAUNCH_EDITOR=code to bypass the detection and use VS Code directly.

Environment

• OS: macOS
• Node.js: v22.14
• launch-editor: uses the package from a middleware in vite