[Bug]: LSP server fails to start on Windows when wrapper script (.bat/.cmd) is needed

[KnifeOfLife]

Prerequisites

• I will write this issue in English (see our Language Policy)
• I have searched existing issues to avoid duplicates
• I am using the latest version of oh-my-openagent
• I have read the documentation or asked an AI coding agent with this project's GitHub URL loaded and couldn't find the answer

Bug Description

Bug Description

On Windows, the lsp-tools-mcp module's resolveWindowsCommand function incorrectly prioritizes extensionless files over .bat/.cmd scripts when resolving commands from PATH. This causes LSP servers that rely on wrapper scripts (like jdtls) to fail with exit code -4058 (UV_ENOENT - file not found).

Root Cause

In packages/lsp-tools-mcp/src/lsp/process.ts, the getWindowsPathExtensions function returns extensions with an empty string "" at the beginning:

function getWindowsPathExtensions(env: Record<string, string | undefined>): string[] {
    const rawExtensions = env.PATHEXT ?? ".COM;.EXE;.BAT;.CMD";
    const extensions = rawExtensions
        .split(";")
        .map((extension) => extension.trim())
        .filter(Boolean)
        .map((extension) => (extension.startsWith(".") ? extension : `.${extension}`));
    return [...new Set(["", ...extensions, ".exe", ".cmd", ".bat"])];
    //                     ^ Empty string first!
}

When resolving jdtls in a directory containing both:

• jdtls (extensionless Python script with shebang)
• jdtls.bat (wrapper script that sets JAVA_HOME and executes with correct JDK)

The function finds jdtls first (because "" extension is checked before .BAT), returns its full path, and then isWindowsShellShim returns false (since it doesn't end with .bat or .cmd), causing Node.js spawn to execute it directly with shell: false.

The problem: Windows does not support shebang (#!/usr/bin/env python3). An extensionless Python script cannot be executed directly without a shell, resulting in UV_ENOENT error.

Proposed Fix

In packages/lsp-tools-mcp/src/lsp/process.ts, move the empty string "" to the end of the extensions array:

// Before (buggy):
return [...new Set(["", ...extensions, ".exe", ".cmd", ".bat"])];

// After (fixed):
return [...new Set([...extensions, ".exe", ".cmd", ".bat", ""])];

This ensures Windows PATHEXT extensions (.COM, .EXE, .BAT, .CMD) are checked first, matching the behavior of cmd.exe when resolving commands.

Steps to Reproduce

1. Install jdtls (Eclipse JDT Language Server) on Windows
2. Configure jdtls with a wrapper script that sets JAVA_HOME to JDK 21:
   • jdtls (extensionless Python script with --java-executable pointing to JDK 21)
   • jdtls.bat (wrapper that sets environment and calls the Python script)
3. Ensure JDK 8 is the system default (JAVA_HOME points to JDK 8)
4. Run any LSP operation (e.g., lsp_diagnostics on a .java file)
5. Observe: LSP server jdtls exited with code -4058

Expected Behavior

The LSP server should start successfully. The command resolution should follow Windows PATHEXT priority order, matching .BAT/.CMD scripts before extensionless files.

Actual Behavior

The LSP server fails to start because the extensionless Python script is executed directly, which Windows cannot handle without shell involvement.

Doctor Output

Opencode version: 1.15.7
oh-my-openagent version: 4.3.0

Error Logs

Configuration

Additional Context

This bug affects any LSP server on Windows that:

1. Has both an extensionless executable and a .bat/.cmd wrapper
2. Relies on the wrapper script for correct environment setup

The current behavior contradicts Windows' native command resolution, where PATHEXT extensions are prioritized over extensionless files.

Operating System

Windows

OpenCode Version

1.15.7

[KnifeOfLife]

Temporarily remove jdtls (extensionless script) and make the code match jdtls.bat, this can solve the problem. However, this is still a bug because Windows does not support the shebang, extensionless script should not be given priority for matching.

[YOMXXX]

Reviewer note from a read-only code pass on current dev commit 77682055fa2e0865a23ca48608745348b6ea46c9: the main LSP server process path appears fixed now.

The current process launcher resolves Windows .cmd/.bat shims and executes them through cmd.exe:

• Windows shim extensions are recognized: https://github.com/code-yeongyu/oh-my-openagent/blob/77682055fa2e0865a23ca48608745348b6ea46c9/packages/lsp-tools-mcp/src/lsp/process.ts#L112-L115
• PATH and PATHEXT resolution happens before spawn: https://github.com/code-yeongyu/oh-my-openagent/blob/77682055fa2e0865a23ca48608745348b6ea46c9/packages/lsp-tools-mcp/src/lsp/process.ts#L122-L146
• .cmd/.bat commands are executed via cmd.exe /d /s /c: https://github.com/code-yeongyu/oh-my-openagent/blob/77682055fa2e0865a23ca48608745348b6ea46c9/packages/lsp-tools-mcp/src/lsp/process.ts#L163-L172
• spawnProcess() uses the resolved spawn command: https://github.com/code-yeongyu/oh-my-openagent/blob/77682055fa2e0865a23ca48608745348b6ea46c9/packages/lsp-tools-mcp/src/lsp/process.ts#L186-L199
• Tests cover explicit .cmd and PATH-only .cmd resolution: https://github.com/code-yeongyu/oh-my-openagent/blob/77682055fa2e0865a23ca48608745348b6ea46c9/packages/lsp-tools-mcp/test/process.test.ts#L81-L116

Remaining risk: the LSP MCP bootstrap script still directly uses spawnSync around npm, so npm.cmd bootstrap handling may need separate coverage if Windows still reproduces startup failure:

oh-my-openagent/src/mcp/lsp.ts

Lines 22 to 31 in 7768205

	"const run = (command, args, stdio) => spawnSync(command, args, { cwd: root, env: process.env, stdio })",
	"const finish = (result) => { if (result.error) { console.error(result.error.message); process.exit(1) } process.exit(result.status ?? 1) }",
	"const runIfAvailable = (command, args) => { const result = run(command, args, 'inherit'); if (result.error) return false; finish(result); return true }",
	"if (existsSync(dist)) finish(run(process.execPath, [dist, 'mcp'], 'inherit'))",
	"if (existsSync(source)) runIfAvailable(bun, [source, 'mcp'])",
	"const submoduleResult = run(git, ['submodule', 'update', '--init', '--recursive', 'packages/lsp-tools-mcp'], ['ignore', 'ignore', 'inherit'])",
	"if (submoduleResult.error || submoduleResult.status !== 0) finish(submoduleResult)",
	"if (existsSync(dist)) finish(run(process.execPath, [dist, 'mcp'], 'inherit'))",
	"if (existsSync(source)) runIfAvailable(bun, [source, 'mcp'])",
	"for (const [command, args] of [[npm, ['--prefix', submodule, 'install', '--no-package-lock', '--no-audit', '--no-fund']], [npm, ['--prefix', submodule, 'run', 'build']]]) { const result = run(command, args, ['ignore', 'ignore', 'inherit']); if (result.error || result.status !== 0) finish(result) }",

Suggested triage: ask for a retest on current dev. If this still fails, split the bootstrap npm.cmd path from the already-fixed language-server process path.

[code-yeongyu]

[sisyphus-dev] I reproduced the root cause in the LSP submodule: when PATH contains both an extensionless jdtls and jdtls.bat, the current resolver checks the empty extension first and can select the extensionless script. I closed the stale/broader related PRs (#4266, #4496) and am opening a replacement that applies the PATHEXT ordering fix on top of the current submodule head with a regression test for this exact wrapper scenario.