Issue with PATH expansion in VSCode subprocess on macOS

[jbevain]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.82.3
• OS Version: Ventura 13.6

This one was tricky to investigate and is impacting the Unity extension and C# & C# Dev Kit scenario. In that scenario, VS Code is started from one application using the macOS open command. This reproduces without requiring Unity and with no extension installed. This seems to be a macOS only issue.

When opening Visual Studio Code either from the macOS Finder or through open, the VS Code application will expand the PATH of its Code Helper subprocess so that extensions that depend on something in the path of the terminal will find it.

So in my case, if I start VS Code from the Finder, the processes will look like this:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)

This is expected and good. Extensions can find dotnet in the PATH.

The issue is that now, if I want to open another workspace in the same instance (but launched from another application), the PATH doesn't get expanded in the second workspace and I get:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)

So in my second workspace, dotnet will not be found in the PATH.

For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal)

Steps to Reproduce:

1. With Xcode, create a new SwiftUI project (I mean, it doesn't have to be a SwiftUI project, you can re-create the issue with anything that is able to output a macOS .app but for this particular repro I used SwiftUI)
2. Disable the Sandbox for the project:

3. Make the ContentView.swift look like this:

import SwiftUI
import Darwin
import Foundation

struct ContentView: View {
    var body: some View {
        VStack {
            Image(systemName: "globe")
                .imageScale(.large)
                .foregroundStyle(.tint)
            Text("Hello, world!")
            Button("Click to Launch") {
                let path = String(utf8String: getenv("PATH"))!
                let newPath = path + ":/lol"
                setenv("PATH", newPath, 1)
                
                let open = "/usr/bin/open"
                let vscode = "/Applications/Visual Studio Code.app"
                let workspace1 = "/Users/jbevain/tmp/ReproMirror"
                let workspace2 = "/Users/jbevain/sources/com.unity.ide.visualstudio"
                
                let p = Process()
                p.executableURL = URL(fileURLWithPath: open)
                p.arguments = ["-n", vscode, "--args", workspace1]

                try! p.run()
                
                Thread.sleep(forTimeInterval: 5)
                
                let p2 = Process()
                p2.executableURL = URL(fileURLWithPath: open)
                p2.arguments = ["-n", vscode, "--args", workspace2 ]
                
                try! p2.run()
            }
        }
        .padding()
    }
}

4. Modify the variables workspace1 and workspace2 to point to 2 different workspaces.

5. Build the project, I personally use xcodebuild in command line.

6. Close all VS Code instances.

7. Start the .app from the Finder, it will be in build/Release if you built from the command line by default.

8. Press the Click to Launch! button

As you can see from the code, the .app will:

1. set the PATH with a marker `/lol`
2. open a new VS Code workspace on workspace1
3. wait a bit
4. open a new VS Code workspace on workspace2

9. Open activity monitor, find the child process ID:

10. In the terminal, look at their path:

ps eww 44049

(Your pid may vary)

11. Observe that the second child process doesn't have its PATH expanded, and only inherited the PATH from the .app:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol)

[TylerLeonhardt]

@joaomoreno I think you're best equip to handle this issue? but feel free to reassign to whoever.

[joaomoreno]

I can't repro this. To know more, please do the following:

• Quit VS Code
• From a Terminal, run open -n /Applications/Visual\ Studio\ Code.app --args WORKSPACE, this should open VS Code
• In that window, run Developer: Set Log Level... and set it to Trace.
• Then, from a Terminal, run open -n /Applications/Visual\ Studio\ Code.app --args WORKSPACE2, this should open the second window
• On the second window, reveal the Output panel and the Window logs. Search for userEnv, what do you find?

[jbevain]

@joaomoreno the entire point of long repro is to not start VS Code from the terminal, but from an app launched from macOS.

As I said in the bug:

For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal)

[joaomoreno]

@jbevain Using open -n APP is the same as launching from Finder. Let me know the result.

[jbevain]

@joaomoreno I'm afraid it's not exactly the same as it exhibits a different behavior as it appears the second instance of the Code Helper process will simply inherit the PATH of the process that started it, instead of expanding the PATH to be like a terminal

• Using open -n twice will work as expected from the Terminal as the second instance of the Code Helper process will inherit the PATH of the Terminal.
• Using the repro steps to create an app that will call open -n on Visual Studio Code twice won't work as expected.

If I close all VSC instances, and do open -n twice on two different workspaces, I get:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)

Things are visibility different as the main Code process seems to inherits the PATH from the Terminal.

Whereas if I launch Code manually from the Finder, I get:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/lol:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)

So there is a difference.

[joaomoreno]

Thanks for testing! Very interesting, I was unaware of differences here. Last I saw this (when I did the macOS integration years ago), open did not propagate environments. It seems like it does now. 🤔

Can you try just once more with: open vscode-insiders://fileWORKSPACE, replacing WORKSPACE with the path to the workspace? Thanks, I really appreciate it!

[jbevain]

Version: 1.84.0-insider
Commit: 55d1cfe

With open vscode-insiders://fileWORKSPACE from the Terminal I get the same behavior as open --args:

Code (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)
    Code Helper (PATH: /usr/bin/:/bin/:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin)

[jbevain]

Hi @joaomoreno, we're seeing a growing number of customer reports on this. I think I've provided all the info that was needed including a way to create a self-contained repro. How could we get this looked at? Thanks!

[lectricas]

Same here guys. Just installed unity + vscode and have this message about missing net sdk.
I came from here. microsoft/vscode-dotnettools#532

[ericdrobinson]

I came here from microsoft/vscode-dotnettools#532 as well – and I'm glad I did! I've been banging my head against the "dotnet isn't on the PATH" issue
(and related!) for quite a long while and with insight from the fantastic writeup for this issue was able to get it to work again. For me, the break comes down to how I open my Unity project in VS Code.

How I Usually Open Unity Projects

I generally open my Unity Projects is with the following:

1. Open the project in Unity.
2. Select "Open C# Project" from the Assets menu.

If the project isn't already open, Visual Studio Code will open up a new window and load the project. When this happens, I get all the "I can't find dotnet!" issues.

How to Open Unity Projects Without the Issue

1. Open a new VS Code window (keyboard shortcut/menu/palette/whatever).
2. Open the project from within VS Code.
   • In my case, I do this via the "Open Recent..." menu as what I'm looking for is usually listed there.

Regardless, if I open the project in VS Code in this manner, everything works as expected.

[joaomoreno]

@jbevain, sorry for the silence here. Let's try to figure this one out.

First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why...

In any case, can I ask you for one more piece of info?

1. Open from Finder (main process regular PATH, Code Helper with sourced PATH)
2. From a Terminal, call the open command with the path to the second workspace.

What's the PATH of that second Code Helper process that comes up? Resolved?

[jbevain]

Hey @joaomoreno, thanks for bumping this, happy new year, looking forward to having a resolution for this.

First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why...

That happened to me before I turned the sandbox off. See step 2 of the repro?

We could also try the real world scenario with Unity, but it's going to be a slightly longer setup, I'd encourage you to reach out to my email at work to help get you setup.

In any case, can I ask you for one more piece of info?
Open from Finder (main process regular PATH, Code Helper with sourced PATH)
From a Terminal, call the open command with the path to the second workspace.
What's the PATH of that second Code Helper process that comes up? Resolved?

In that case:

The main Visual Studio App inherits the PATH of the Finder (so just /usr/bin:/bin)
The first Code Helper (Plugin) process gets a PATH expended.
The second Code Helper (Plugin) process inherits the PATH of the Terminal, verified by doing:

export PATH=$PATH:/foo

Just before calling open -n in the Terminal.

[joaomoreno]

That happened to me before I turned the sandbox off. See step 2 of the repro?

🤦 Sorry about that. It runs correctly now! And I can repro!

Funny: it seems to only affect the PATH variable. If, say, one adds export FOO=bar to .zshrc, that gets properly propagated to both extension hosts (Code Helper (Plugin)). Interesting, digging more...

[jbevain]

And I can repro!

Nice! Good luck :)

[joaomoreno]

Got it! 🥳

[VSCodeTriageBot]

This bug has been fixed in the latest release of VS Code Insiders!

@jbevain, you can help us out by commenting /verified if things are now working as expected.

If things still don't seem right, please ensure you're on version 8172579 of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.

Happy Coding!

[jbevain]

/verified