feat: support opening folders on Mac with vscode

[ulugbekna]

Add Install 'Open with Code' in Finder and Uninstall 'Open with Code' from Finder commands under the Shell Command category (macOS only).

These commands install/uninstall a macOS Automator Quick Action workflow to `~/Library/Services/` that adds an 'Open with {productName}' entry to the Finder right-click context menu (Quick Actions / Services).

The workflow runs `open -a "{appName}" "$@"` to open selected files/folders in VS Code.

Each VS Code build (Stable, Insiders, OSS) creates a distinctly-named workflow, so multiple installations coexist without conflict.

How to use

1. Open VS Code
2. Command Palette → Shell Command: Install 'Open with Code' in Finder
3. Right-click a folder in Finder → Quick Actions / Services → Open with Code

Files changed

• `src/vs/platform/native/common/native.ts` — added `installFinderAction` / `uninstallFinderAction` to interface
• `src/vs/platform/native/electron-main/nativeHostMainService.ts` — implementation (generates Automator .workflow bundle)
• `src/vs/workbench/electron-browser/actions/installActions.ts` — action classes
• `src/vs/workbench/electron-browser/desktop.contribution.ts` — registration
• `src/vs/workbench/test/electron-browser/workbenchTestServices.ts` — test stubs

Demo

CleanShot.2026-03-17.at.12.08.33.mp4

[vs-code-engineering]

📬 CODENOTIFY

The following users are being notified based on files changed in this PR:

@bpasero

Matched files:

• src/vs/platform/native/common/native.ts
• src/vs/platform/native/electron-main/nativeHostMainService.ts
• src/vs/workbench/electron-browser/actions/installActions.ts
• src/vs/workbench/electron-browser/desktop.contribution.ts

[Copilot]

Pull request overview

Adds macOS-only commands to install/uninstall a Finder “Quick Action / Services” workflow that opens selected files/folders in VS Code via open -a ..., integrating with the existing Shell Command action area.

Changes:

• Extend ICommonNativeHostService with installFinderAction / uninstallFinderAction.
• Implement Finder workflow generation/removal in the Electron main native host service.
• Add and register new workbench actions (macOS only) and update test stubs.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/vs/platform/native/common/native.ts	Adds new native host API methods for Finder action install/uninstall.
src/vs/platform/native/electron-main/nativeHostMainService.ts	Implements workflow bundle creation/removal under ~/Library/Services.
src/vs/workbench/electron-browser/actions/installActions.ts	Adds new command palette actions to invoke the native host APIs.
src/vs/workbench/electron-browser/desktop.contribution.ts	Registers the new actions on macOS.
src/vs/workbench/test/electron-browser/workbenchTestServices.ts	Updates native host test stub to match the new interface.

Comments suppressed due to low confidence (1)

src/vs/platform/native/electron-main/nativeHostMainService.ts:692

• productService.nameLong is embedded into the document.wflow XML command string without XML escaping. If it ever contains &, <, >, or ", the workflow file will be invalid. Please XML-escape interpolated values before writing the plist.

			'\t\t\t\t<dict>',
			'\t\t\t\t\t<key>COMMAND_STRING</key>',
			`\t\t\t\t\t<string>open -a "${appName}" "$@"</string>`,
			'\t\t\t\t\t<key>CheckedForUserDefaultShell</key>',

[bpasero]

This is nice, but can you clean the diff to be minimal, I find it hard to review, there seems to be unrelated changes around import sort order and some on did blur event that moved.

[bpasero]

@deepak1556 adding you, maybe you have thoughts as well how to do this on install time or from our existing info.plist file where we register handlers for common file types.

[ulugbekna]

@bpasero thank you! minimized diffs and removed unrelated changes (which came from background session applying changes without my consent, I believe)

[deepak1556]

Could we have a native module handle the service callback, the module can register itself as a service provider, the service provider can also implement menu validation that would either enable or disable the menu. This also has the nice benefit of having the service menu declaration as part of our app bundles info.plist.

[ulugbekna]

@deepak1556 do I understand it correctly that the native approach would involve these todos?

1. Creating a new native Node addon with Objective-C++ code
2. Adding build infrastructure (binding.gyp, compilation step)
3. Adding NSServices to Info.plist via sign.ts
4. Replacing the Automator workflow code with native service provider registration

[deepak1556]

1, 2 and 3 correct

4. Correct, the module initialization code can register itself as the service provider (the init code would run on module load). Then have the module expose an api that would allow you to enable/disable the menuitem from JS based on the actions you have in this PR.