resolveWindowsAppPath passes [object Promise] instead of actual path — editor launch broken on Windows #27432

Description

Describe the Bug
On Windows, the resolveWindowsAppPath function in the main process fails to resolve editor paths (e.g., code, cursor, zed). It incorrectly returns the literal string "[object Promise]" instead of the actual filesystem path, causing editor launches to fail silently.

Root Cause
In out/main/index.js (v1.14.49, line 60), the asynchronous execFile call is handled incorrectly:

JavaScript
// File: out/main/index.js
async function resolveWindowsAppPath(appName) {
let output;
try {
// BUG: Missing await and incorrect property access
output = execFilePromise("where", [appName]).toString();
} catch {
return null;
}
}
The Issue: execFilePromise (created via util.promisify) returns a Promise. Calling .toString() on a Promise object immediately returns "[object Promise]" without waiting for resolution.

The Result: The catch block becomes dead code (since .toString() won't throw), and the app attempts to spawn a process using the string "[object Promise]" as the executable path.

Suggested Fix
Update the function to properly await the promise and extract stdout:

JavaScript

async function resolveWindowsAppPath(appName) {
let output;
try {
// Fix: await the promise and access the stdout property
const result = await execFilePromise("where", [appName]);
output = result.stdout;
} catch {
return null;
}
}

Plugins

No response

OpenCode version

v1.14.49

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response