Things missing from PATH variable in OS X Big Sur

[bwateratmsft]

• VS Code Version: (various)
• OS Version: OS X Big Sur

We have not been able to reproduce this issue ourselves, but have seen a lot of users hitting problems with the PATH variable missing some things on Big Sur. It does not happen when running the Terminal app nor within terminals manually-launched within VSCode, but does seem to happen when things execute as tasks or in the background via child_process.

As a result of missing entries, commands like docker ... fail.

microsoft/vscode-docker#2758 (ended up being terminal.integrated.inheritEnv == false)
microsoft/vscode-docker#2366
microsoft/vscode-docker#2254
microsoft/vscode-docker#2574
microsoft/vscode-docker#2577

Maybe related to #115738 or #21655?

[TylerLeonhardt]

@bwateratmsft I feel like I've seen this when I launch VS Code from the dock rather than using code . in a terminal to launch VS Code... this is because the environment is inherited differently. Can you confirm with your users on this?

[bwateratmsft]

That's something we have seen as well, due to a 10+ year old bug in OS X. As far as I can tell though, lately it's not always happening due to launching from the Dock or Spotlight; and also seems way more frequent on Big Sur than before--which makes me wonder if this is more recent/widespread; i.e. some kind of regression.

[deepak1556]

with 1.54 vscode child process will use posix_spawn instead of fork on Big Sur and later versions. If you hitting this issue specifically in child processes then it could be very likely the culprit. Versions before 1.54 don't have this change so that could be a different factor.

From the issues you have linked, they seem to be on older versions that what I had mentioned. Would help if there is a minimal repro to debug further on newer versions.

[bwateratmsft]

That's the kicker...we've never been able to repro this in-house. 😞

[deepak1556]

Next time, can you ask the users to launch vscode like

NODE_DEBUG='child_process' code --verbose

This should print some verbose logs of what is passed into the child_process calls that might add some insight to the issue

[bwateratmsft]

Good idea, I'll try that next time we see the issue occur. Hopefully it won't happen soon...we took a change so that if we don't see /usr/local/bin on the PATH variable (which is where docker is almost always located), we'll temporarily add it before calling child_process. I'm not real excited about that approach because it seems wrong to manipulate the PATH variable, but we wanted to try to help our users in whatever way we could.

[hugoiko]

I've started having this issue out of nowhere today. I'm on macOS Catalina with VS Code 1.54.1. I have a shell task that simply runs docker-compose build, which fails because it cannot find docker. That might be related to @deepak1556 comment about posix_spawn. Things are missing on the PATH as well.

EDIT: a dirty workaround is to add "options": {"env": {"PATH": "${env:PATH}"}} to the task.

EDIT2: launching from the dock or using code . doesn't make a difference in my case.

[deepak1556]

@hugoiko can you provide the output from #118460 (comment) if you can repro this issue. Thanks!

[ivarley]

FWIW, I was able to reproduce similar behavior when VSCode was launched automatically after a reboot—the PATH was all screwed up (I noticed because a dependency I was using in a jupyter notebook, pandoc, wouldn't resolve because it wasn't on the PATH). Launching (via Quicksilver) gave me the right path, but auto-launch after reboot did not.

[chrmarti]

We continue without the env variables from the shell if retrieving them takes more than 10 seconds which is more likely to happen when the machine is under load (like during startup). We used to have a notification in the UI for this, but now it only appears in the log.

vscode/src/vs/platform/environment/node/shellEnv.ts

Line 62 in 2750398

const timeout = setTimeout(() => {

Remote-Containers is now also adding /usr/local/bin to the PATH on Mac if it is not there after receiving multiple reports of docker not being available even though it should.

[bwateratmsft]

Remote-Containers is now also adding /usr/local/bin to the PATH on Mac if it is not there after receiving multiple reports of docker not being available even though it should.

We ultimately ended up doing the same thing in the Docker extension.

[cdevoogd]

I believe I am encountering the same issue on macOS Monterey 12.0.1 and VSCode 1.63.0.

~
❯ sw_vers
ProductName:	macOS
ProductVersion:	12.0.1
BuildVersion:	21A559

~
❯ code --version
1.63.0
7db1a2b88f7557e0a43fec75b6ba7e50b3e9f77e
x64

I noticed the issue when my Go extension was not loading the proper $GOPATH variable (was complaining about missing tools) when VSCode was launched from the dock, but was fine when launched from the terminal or Raycast (spotlight replacement).

---

Here are some screenshots from launching VSCode in different ways.

• Different methods seem to behave differently.
• I included output of some relevant environment variables from the dev tools
• I also included the output of what the Go extension thinks the current GOPATH is

A few notes that may be helpful when looking at the following logs/screenshots (I am including GOPATH info too since that is how I noticed the issue):

• My default shell is fish, and not the macOS default of zsh
• My environment variables for fish are set in the normal user config file: ~/.config/fish/config.fish
• My GOPATH should be set to /Users/cam/.go (notice the dot). This is what I have set in config.fish.
• The default GOPATH (if I hadn't set it) would just be /Users/cam/go (no dot)

Launched using code in the terminal

• GOPATH and PATH match what is defined in my config.fish file
• Shell is correct

Launched using Raycast

• Dev tools don't show my custom PATH or GOPATH, but the Go extension seems to have found the GOPATH
• Shell is correct

Launched using Spotlight

• Seems to be the same as raycast

Launched from dock icon

• Shell is zsh instead of fish
• Go is unable to find GOPATH
• Go complaining about missing tools (this is what keyed me in on this issue)

---

I also have logs from launching VSCode from the terminal using NODE_DEBUG='child_process' code --verbose as recommended above. Of course, these are launching from the terminal (which works properly). I am not sure if there is a way to provide this kind of information when launching from the dock. If there is, just let me know.

These are the logs I get when I run the command with no instances open:
verbose-fresh-launch.txt

These are the logs I get when I run the command while a VSCode instance is already open:
verbose-code-already-launched.txt

[therealchjones]

Likely the same problem with minimal reproducible steps in #145434. Behavior appears to be (at least) in tasks on macOS when:

• path is not set in task options
• code is not launched from command line
• path is set in settings.json via terminal.integrated.env.osx

Unfortunately the requirement not to launch from the command line obviates the possibility of the node debug logs in the usual fashion. Happy to try another way if possible.

[divmgl]

I'm having this issue right now with devcontainers. We ask our developers to include some secrets in their environment so that the containers can get built correctly. This all works when using code . because the environment variables are present. Some of the developers use ~/.zshrc to load them and some use direnv.

Anyhow, I've had to tell my developers to only open Code from the command line, which is a bit of a pain but not a showstopper.

Edit: my only workaround is to run launchctl setenv in my script files. I'd really rather not do this... surely there's a way we can do this at the VSCode level.

[therealchjones]

I'm having this issue right now with devcontainers. We ask our developers to include some secrets in their environment so that the containers can get built correctly. This all works when using code . because the environment variables are present. Some of the developers use ~/.zshrc to load them and some use direnv.

Anyhow, I've had to tell my developers to only open Code from the command line, which is a bit of a pain but not a showstopper.

Edit: my only workaround is to run launchctl setenv in my script files. I'd really rather not do this... surely there's a way we can do this at the VSCode level.

@divmgl The environment can be set in many ways in Code itself depending on the desire to use it in Tasks, Terminal, or other components. Would that be a better solution for your use case than setting the shell environment which is, as you note, somewhat less consistently imported?

[therealchjones]

I can confirm this to be an ongoing issue in macOS Monterey 12.2.1 and VSCode 1.65.2.

To reproduce:

• Include ${env:PATH} in the path set in terminal.integrated.env.osx in workspace or user settings
• Launch VS Code in macOS from the Dock or otherwise without using the command line
• Run a task without an explicit PATH setting

Result:

• the PATH in the environment Code runs under is set by launchd(8)/launchctl(8), by default /usr/bin:/bin:/usr/sbin:/sbin; this can be verified in the Developer Tools console as process.env
• the PATH in the environment the task runs under is then also /usr/bin:/bin:/usr/sbin:/sbin

Workaround:

• if PATH is not set in terminal.integrated.env.osx, tasks will set it from the environment used in a typical interactive login shell for the user (some caveats apply; this partially contradicts the documentation at https://code.visualstudio.com/docs/editor/tasks#_why-do-i-get-command-not-found-when-running-a-task)
• if PATH is set in the options.env settings for the task, this will override the terminal.integrated.env.osx setting; non-intuitively (as noted in Inconsistent behavior of ${env:PATH} #145434), ${env:PATH} in the task options does substitute the PATH from a typical interactive login shell rather than the environment Code is running under.

[divmgl]

The environment can be set in many ways in Code itself depending on the desire to use it in Tasks, Terminal, or other components. Would that be a better solution for your use case than setting the shell environment which is, as you note, somewhat less consistently imported?

Yeah the issue I'm having might be tangentially related to this one (and maybe I'll create a new issue in GitHub), but IMO the problem is a symptom of the same action: launching VSCode from the dock in MacOS. Here's a StackOverflow question I just flagged with a bounty.

https://stackoverflow.com/questions/70227082/configuring-environment-variables-prior-to-creation-of-dev-container

In the devcontainer when I use source .envrc I get:

I'm assuming this is because devcontainer builds are run with no shell. But there has to be somewhere the command is running. I'm assuming it's posix_spawn. When I use dot in POSIX, I get:

I'd like for VSCode to just pass in the environment variables from my shell. Like, the shell is correct in process.env.SHELL:

But the environment variables are all missing:

Contrast this to when I launch from the terminal:

[ostwilkens]

When launching vscode through spotlight, raycast, or finder, I get this error when trying to build my dotnet project.
If I launch vscode through the terminal, this error does not occur, likely because the PATH includes dotnet folders.

> Executing task: dotnet build /Users/ostwilkens/Projects/UnlimitedShaderForks2/UnlimitedShaderForks/UnlimitedShaderForks.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary <

The terminal process failed to launch: Path to shell executable "dotnet" does not exist.

Terminal will be reused by tasks, press any key to close it.

[therealchjones]

When launching vscode through spotlight, raycast, or finder, I get this error when trying to build my dotnet project. If I launch vscode through the terminal, this error does not occur, likely because the PATH includes dotnet folders.

> Executing task: dotnet build /Users/ostwilkens/Projects/UnlimitedShaderForks2/UnlimitedShaderForks/UnlimitedShaderForks.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary <

The terminal process failed to launch: Path to shell executable "dotnet" does not exist.

Terminal will be reused by tasks, press any key to close it.

@ostwilkens Please see this comment for possible workarounds, let us know if one of those doesn’t work. Thanks!

[ostwilkens]

When launching vscode through spotlight, raycast, or finder, I get this error when trying to build my dotnet project. If I launch vscode through the terminal, this error does not occur, likely because the PATH includes dotnet folders.

> Executing task: dotnet build /Users/ostwilkens/Projects/UnlimitedShaderForks2/UnlimitedShaderForks/UnlimitedShaderForks.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary <

The terminal process failed to launch: Path to shell executable "dotnet" does not exist.

Terminal will be reused by tasks, press any key to close it.

@ostwilkens Please see this comment for possible workarounds, let us know if one of those doesn’t work. Thanks!

Thank you for the quick reply!
But I'm sorry to say I don't fully understand the workarounds. I'm having no luck with the options listed.

My findings:

• Dotnet adds itself to PATH in a peculiar way, not using any rc or profile files: dotnet command doesn't exist on macOS dotnet/runtime#3603 (comment)
• According to this stackoverflow post, "Mac does not have a configuration options that sets environment variable for all contexts."
  This leads me to think that my task will have to source my rc file. However,
• Tasks that are run in vscode do not seem to source .zshrc, .zshenv, .profile or .bash_profile, no matter what.
  • Adding or removing the following options have no effect on this:
    • "terminal.integrated.defaultProfile.osx": "zsh"
    • "terminal.integrated.env.osx": { "PATH": "${env:PATH}" }
    • "terminal.integrated.inheritEnv": true
    • "options": { "env": { "PATH": "${env:PATH}" } } (on the task)
    • "options": { "shell": { "args": ["-c", "-l"] } } (on the task)

[ostwilkens]

Changing the task type from process to shell fixed the PATH issue.
The default build tasks had it set to process.

[therealchjones]

@ostwilkens, I'm afraid there are a couple of issues in your comment that aren't quite right. I'm going to reply to them directly here, then add a follow-up comment with more generic comments about how macOS and Visual Studio Code are coming up with the environments in which to run things. The issue is obviously overcomplicated, as you've figured out and referenced very nicely, but there's unfortunately a great deal of misunderstanding out there, primarily due to recommendations that worked on previous versions of macOS but don't anymore.

There's plenty of discussion in the dotnet issue you link about how it all "should" work, and I'm going to try to avoid that, but dotnet on macOS does add itself to the path in a common macOS way; it just happens not to be a common way on other platforms. And similar to that mechanism, macOS still does have a launchctl or launchd process that "sets environment variables for all contexts" (the "user" one alone doesn't work anymore, but the system version does), but many of those contexts (such as the terminal) overwrite or otherwise change those variables. This is a big part of what makes this issue in VS Code so difficult to troubleshoot and fix---there are so many different processes changing things around that it frequently doesn't seem to work "as expected".

I'm very interested to hear that your problem seems to be solved by using the "process" type as it doesn't "look" at first glance like that should change the way VS Code develops the environment on Linux and macOS. Definitely will need to test more myself. Most importantly, of course, I'm glad you got it working!

[therealchjones]

Work in progress: PATH in macOS and VS Code

[ostwilkens]

@therealchjones that's a great document for understanding the functionality!
Hopefully somewhere in the future it won't be required reading for everyone installing dotnet on a mac.

Oh, and it was the "shell" type that fixed the problem with the tasks. However, I'm sorry to say OmniSharp isn't happy about dotnet not being in PATH, and fails to run debugging. I'm back to launching vscode from the terminal.

[divmgl]

@therealchjones that is a GREAT document, thank you!

[deepak1556]

We have made some process architecture changes over the last couple of months for the extension host, does this issue repro with latest insiders https://code.visualstudio.com/insiders ?

[bwateratmsft]

@deepak1556 we've made a lot of changes in the Docker extension too; likely they will make it more sensitive to issues with $PATH. So far we haven't seen any customer reports of problems that look like $PATH issues, but I'll respond back if we see anything.

[bwateratmsft]

We have another user hitting it here: microsoft/vscode-docker#3811

/usr/local/bin is normally on the PATH but is missing for whatever reason when this user runs VSCode.

[bwateratmsft]

Also, #173480 seems the same as or similar to this.

[vscodenpa]

Hey @deepak1556, this issue might need further attention.

@bwateratmsft, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[vscodenpa]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!