fix(editor): execute oxc.path.server in win32 with shell, when its the node_module binary

[Sysix]

closes #14167
This allows cross-platform configuration in a project.
The project can now define oxc.path.server to node_modules/.bin/oxc_language_server and windows will pick it up too.

With validateSafeBinaryPath in Pathvalidator.ts, we should be sure that bad actors can not harm the user's machine.

[Sysix]

• fix(editor): execute oxc.path.server in win32 with shell, when its the node_module binary #14203 👈 (View in Graphite)
• fix(editor): stricter path validation for oxc.path.server #14202
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull Request Overview

This PR fixes cross-platform support for the oxc language server by enabling Windows to execute npm binary scripts through shell execution when the user configures oxc.path.server to point to node_modules/.bin/oxc_language_server.

• Modifies the binary execution logic to use shell mode on Windows for node_modules binaries
• Updates path validation comments to reflect the new shell usage
• Enables cross-platform configuration where projects can define a single path that works on all platforms

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
editors/vscode/client/extension.ts	Adds conditional shell execution for Windows node_modules binaries and refactors findBinary function
editors/vscode/client/PathValidator.ts	Updates comment to reflect that shell execution is now used on Windows

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[nrayburn-tech]

Is this because windows can’t execute this script directly? I think there’s another alternative to spawn a cmd prompt with the argument to execute the script, then you don’t need shell: true.

Not sure if it matters or if there’s any reason to prefer one or the other.

[Sysix]

Yes, it does not handle the sh shebang in the file. Calling the CMD file or ps1 file inside node_modules/.bin/ will not work. This is the only solution or searching for the .exe file.
But searching for the .exe file will create more problems with the location of the .exe.
Your examples in the issue did not check for different package versions. Calling the wrapper script in node_modules/.bin/ "should" be the right way.

[nrayburn-tech]

I don’t personally think this (or the other path validations) are necessary.

If the user has opted into the trusted workspace, they have consented to these settings. I don’t think the extension is responsible for validating what the path might look like or what the contents of the evaluated file might be.

It has potential to make it harder for users to use, for what I would consider little to no real security benefit.

[Sysix]

A user would trust the extension more than a freshly opened workspace. Even when a user has trusted a workspace by accident (when the workspace is inside a parent folder, which is already been trusted). Opening the extension to execute untrusted binaries / shell script should still be validated.
Maybe not all restrictions are needed and can frustrate users to set up the oxc.path.server correctly.
But I will take the cost for better end-user security.

[nrayburn-tech]

I think what you’re trying to solve is possibly a gap in the trusted workspace feature. Instead of trusting an entire workspace, you want users to trust specific values within the workspace. It doesn’t feel like the responsibility of the extension.

I think the definition of setting the oxc.path.server “correctly” is subjective. If I want to use whatever characters in my path, that shouldn’t be prevented by the extension.

I understand the desire for security though. I don’t think this is a blocker by any means, just wanted to bring it up as something to consider.

[nrayburn-tech]

I won’t be able to actually review any code for a few days, but I don’t think I’ll have much to share other than the few considerations I mentioned before.

Just things for the team to consider.

For what it’s worth, the IntelliJ plugin doesn’t do any path validation and it’s not something I would personally add. The IntelliJ plugin also uses some abstraction provided by IntelliJ, but I believe by default it executes the same file that is being suggested for this PR. However, if a user specifies an exe path directly, that still works too. Specifying an exe path directly just won’t work cross platform (in typical scenarios).

---

I think I mentioned this a while ago when the IDE development was only beginning. It might be beneficial to have documentation on how we want the different IDE plugins owned by the Oxc team to function. This would provide users with a consistent experience across the different IDEs. Currently, users likely have a slightly different experience between the various IDEs (VS Code, IntelliJ, Zed, etc.)