Problem

Various tools don't operate correctly depending on the order and the manner with which VSCode is started on macOS.

Also, persisted state is not restored consistently.

Note: the problem is similar to atom/atom#4126. Although I feel dirty pointing you to a thread pertaining to That Other Editor, the issue is largely the same and some discussion happened over there that one may want to look into for the full effect.

Cause

Depending the manner in which VSCode is started, a different environment is inherited.

• launchd event: inherits launchd mostly blank env, which would mean no shell env vars save from some magic happening and my env vars from a login shell are set (good!)
• code in the terminal: inherits currently set vars

This applied to when the app is started, not when a new window is opened, in which case that window will inherit the current process env (which is normal OS X behaviour).

Current workaround / Anti-feature

Manually control Code startup each time you want to use it in a specific environment.

Why is it an anti feature? If you want two projects open at the same time but with different environments, you're busted.

Also, long running sessions and "wait what env was that started with already?" (session can also mean the idiomatic "document != app" macOS way: "Visual Studio Code.app is started but no windows are opened").

Also also, frustration quickly sets in when you start it up the wrong way and have to quit and restart halfway through your work and notice your linter does not actually run (manual config does not cut it because 1. it's manual and 2. constantly changing versions means constantly changing path).

Possible solution

1. sanitize environment upon every launch, with local environment management is bestowed to package implementor (meaning detection of .git, Gemfile, .rubocop.yml, .gopath, which they have to do anyway else at least starting via launchd is broken, if not more), not to manual handling by developer.
2. have a clean environment per window (which means per process apparently), which is what Atom chose to do but this approach is fraught with peril.

Consequences

• PATH & al. is properly set and tools like linters can leverage the env to use chruby/rbenv/whatever.
• Clicking the icon, starting via spotlight, opening a file from Finder, using open -a "Visual Studio Code" and using code foo on the terminal are all consistent, whatever the order they are executed in.
• Everything is now consistent and we can now rejoice as glittery roses spontaneously bloom out of Bose-Einstein condensates.

Additional note

On another planet, I don't know if this issue applies to other OSes as well besides macOS. Everything depends on how process management and app/doc/task GUI model is expected to be handled there.

Final word

All of this really matters daily when you juggle between projects and makes VSCode feel like a brittle product, making angry coworkers throwing rusted nails at me for having pushed VSCode on them. (I realise I pushed the same argument forward on the Atom issue, but hey, we all know deep inside that VSCode is OvbiouslyBetter™, and being thrown sharp objects at twice is doubleplus unfun).

Details

• VSCode Version: Code 1.7.1 (02611b4, 2016-11-03T13:46:00.226Z)
• OS Version: Darwin x64 16.1.0
• Extensions:

Steps to Reproduce:

1. open VSCode from Dock/Spotlight
2. toggle developer tools and look at process.env in JS console
3. open terminal
4. export FOO=bar
5. run code somewhere or whatever
6. toggle developer tools in new window and look at process.env in console, notice there's no FOO
7. quit VSCode completely (for real)
8. run code somewhere or whatever
9. toggle developer tools in new window and look at process.env in console, notice there's FOO
10. open new code window
11. toggle developer tools in new window and look at process.env in console, notice there's FOO
12. open new terminal tab (that will not have FOO)
13. run code somewhereelse or whatever
14. toggle developer tools in new window and look at process.env in console, notice there's FOO