Does not work on El Capitan

[johnrizzo1]

It looks like since many functions in launchctl were deprecated this approach does not work.

cat ~/Library/LaunchAgents/environment.plist

envsync local.envsync ProgramArguments sh -c launchctl setenv foo "bar" RunAtLoad

launchctl load ~/Library/LaunchAgents/environment.plist
/Users/.../Library/LaunchAgents/environment.plist: Operation not permitted

launchctl setenv foo "bar"
Not privileged to set domain environment.

load is apparently now a "Legacy Subcommand". The setenv subcommand also has issues.

[MarkCallow]

I am having problems on El Capitan too, specifically with Xcode 7. I'm not aware of other apps, that don't read my .bash_profile, that I could use to display the environment they receive so have not tested with anything else.

I do not see the errors @johnrizzo1 reports.

$ launchctl setenv DOXYGEN_BIN /Applications/Doxygen.app/Contents/Resources/doxygen
$

Perhaps this is because I have disabled SIP (System Integrity Protection). Nevertheless the environment is not being propagated.

There are no errors on the console either.

[MarkCallow]

I am having problems on El Capitan too, specifically with Xcode 7. I'm not aware of other apps, that don't read my .bash_profile, that I could use to display the environment they receive so have not tested with anything else.

I do not see the errors @johnrizzo1 reports.

$ launchctl setenv DOXYGEN_BIN /Applications/Doxygen.app/Contents/Resources/doxygen
$

Perhaps this is because I have disabled SIP (System Integrity Protection). Nevertheless the environment is not being propagated.

There are no errors on the console either.

[MarkCallow]

If I start Xcode after logging in then it sees the settings.

If Xcode is auto-started during login as part of reopening windows that were open at previous login, it does not see the settings. That was the state when I added my previous comment.

If I then exit Xcode and run it again, it sees the environment settings.

It looks like Xcode is being auto-started before the launchctl stuff is run. The behavior seems consistent so appears to be due to a deliberate ordering choice.

NOTE: I subsequently discovered a reference, that I now cannot find, that states the ordering of startup items is undefined in OS X. So it is quite possible for auto-start items to be started before the launchctl stuff that sets the environment.

[ersiner]

@johnrizzo1 Perhaps your user is not an "Admin" user. I cannot think of any other reasons of those errors. I'm also on El Capitan and I've never faced such error messages in my setup.

@msc- So I'm assuming your problem is solved (or never existed).

[MarkCallow]

The problem happens every time Xcode is auto-started during login so no the problem is not solved.

I have to make sure not to leave Xcode running when I logout or quit and restart it after login for it to see the environment.

[dan-tull]

I didn't see the permission errors John mentioned, but launchctl setenv is not working for me, either (I'm also using El Capitan). I was trying to get some additional entries in my PATH variable to apply inside the Atom text editor (so some plugins that invoke CLI commands find them properly).

Creating a Launch Agent plist to directly run the launchctl setenv command for the PATH will cause launchctl getenv to produce the intended path in Terminal, but not for other apps (like Atom). This is the case whether I load the service directly with launchctl load from Terminal or just log out and log back in to let the system run it.

I've jumped through the various versions of the proper recipe for setting variables durably in versions of OS X dating back to 10.5, but in 10.11 nothing I've tried has stuck. I finally had to resort to launching Atom from a Terminal.

Edited: Removed mention of environment variable expansion, which was not correct and distracts from the central issue.

[ersiner]

Well, this all used to be working on both Yosemite and El Capitan. Now I observe strange things:

Get the process id of Atom app running:

ps ax | grep /Applications/Atom.app/Contents/MacOS/Atom

Use launchctl procinfo command to list environment variables and other process info as controlled by OS X for the process:

sudo launchctl procinfo <process_id>

In my case the relevant output is as follows:

    inherited environment = {
        MANPATH => /usr/local/opt/erlang/lib/erlang/man:/usr/local/opt/coreutils/libexec/gnuman:/usr/share/man:/usr/local/share/man:/usr/local/opt/coreutils/libexec/gnuman
        PATH => /a:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/a:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/opt/go/libexec/bin:/Users/ersiner/go/bin:/Users/ersiner/bin:/usr/local/opt/go/libexec/bin:/Users/ersiner/go/bin:/Users/ersiner/bin
        LANG => en_US.UTF-8
        LC_ALL => en_US.UTF-8
        GOPATH => /Users/ersiner/go
        JAVA_HOME => /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home
        SSH_AUTH_SOCK => /private/tmp/com.apple.launchd.n4M48nI1ok/Listeners
        Apple_PubSub_Socket_Render => /private/tmp/com.apple.launchd.DZiHkV69S9/Render
    }

    default environment = {
        PATH => /usr/bin:/bin:/usr/sbin:/sbin
    }

    environment = {
        USER => ersiner
        LOGNAME => ersiner
        PATH => /usr/bin:/bin:/usr/sbin:/sbin
        SSH_AUTH_SOCK => /private/tmp/com.apple.launchd.n4M48nI1ok/Listeners
        Apple_PubSub_Socket_Render => /private/tmp/com.apple.launchd.DZiHkV69S9/Render
        HOME => /Users/ersiner
        SHELL => /usr/local/bin/bash
        __CF_USER_TEXT_ENCODING => 0x1F5:0x0:0x0
        TMPDIR => /var/folders/sd/mxnfcpyj5_lg3wd36mkyz9zc0000gn/T/
        XPC_SERVICE_NAME => com.github.atom.106592
    }

There are three sections here: inherited environment (which has all environment variables from my .bash_profile as intended), default environment (the source of mess as it seems) and environment.

When I launch the Atom console (Cmd+Alt+i) and type process.env I get (without any additional packages installed):

...
GOPATH: "/Users/ersiner/go"
HOME: "/Users/ersiner"
JAVA_HOME: "/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home"
LANG: "en_US.UTF-8"
LC_ALL: "en_US.UTF-8"
LOGNAME: "ersiner"
MANPATH: "/usr/local/opt/erlang/lib/erlang/man:/usr/local/opt/coreutils/libexec/gnuman:/usr/share/man:/usr/local/share/man:/usr/local/opt/erlang/lib/erlang/man:/usr/local/opt/coreutils/libexec/gnuman"
NODE_ENV: "production"
NODE_PATH: "/Applications/Atom.app/Contents/Resources/app.asar/exports"
PATH: "/usr/bin:/bin:/usr/sbin:/sbin"
SHELL: "/usr/local/bin/bash"
SSH_AUTH_SOCK: "/private/tmp/com.apple.launchd.n4M48nI1ok/Listeners"
TMPDIR: "/var/folders/sd/mxnfcpyj5_lg3wd36mkyz9zc0000gn/T/"
USER: "ersiner"
...

So the PATH environment variable is being overrided by the "default environment" when launching the process. Other variables like GOPATH or JAVA_HOME have intended values in the Atom environment.

I could not find any reference to these different "environments" in Apple's documentation. Maybe there have been changes to how these all handled in the system recently. I'll dig more soon but you may want to share your our outputs of the same commands here which may help. Also outputs from Yosemite would be great if any of you still using it.

[dan-tull]

I do indeed also have a default environment entry that is stomping PATH (as reflected by process.env in the console in Atom).

My inherited environment is shorter (I had only set PATH via launchctl) but I do also have SSH_AUTH_SOCK and Apple_PubSub_Socket_Render, which are apparently being set by the system.

It looks like we're hitting the same issue. Good find with that procinfo subcommand. I look forward to hearing if you find out more about the default environment that's hosing this up.

[dan-tull]

Curious. When I launch Atom from Terminal (via Atom's own atom command line shortcut, available if you're run "Install Shell Commands" in the app menu), the inherited, default, and environment sections remain but the default one does not appear to take precedence and the augmented PATH from inherited comes through unmolested.

I notice there's an extra argument to the program:
--path-environment=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

I'd have to go digging in Atom's repo, but it looks like they've run into this and added an extra command line argument to funnel through and re-stomp the PATH environment variable.

Update: Confirmed: electron/electron#550

[MarkCallow]

I suffered an indentical problem to @dan-tull's in Yosemite (could never modify $PATH) but it was with Xcode. Eventually I gave up and found workarounds that did not require modifying $PATH. The problem continues in El Capitan. It might be that whatever launchctl behavior was applied to Xcode in Yosemite is now applied to all applications.

The problem with auto-start that I reported earlier in this thread is for any environment variable other than $PATH.

[mgol]

@ersiner I confirm your observations: launchctl procinfo shows correct PATH in the inherited environment section but the default environment one is the one being used by the app.

[xapple]

Xcode 7.0+ doesn't evaluate environment variables by default. The old behaviour can be enabled with this command:

defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NO

[dan-tull]

I'm presuming the "improved environment sanitization" security fixes are behind this:
http://www.securityweek.com/apple-releases-patch-os-x-vulnerability-exploited-wild

Inconvenient, but not without cause from a security standpoint, I guess. So far, I haven't found any details on how this sanitization works or how to alter the default PATH value.

[mgol]

@xapple

Xcode 7.0+ doesn't evaluate environment variables by default. The old behaviour can be enabled with this command:

defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NO

This didn't help; SourceTree still sees PATH only as /usr/bin:/bin:/usr/sbin:/sbin.

I know it's possible to fix as it worked for me on my old MacBook before I changed it about 2 weeks ago. But I don't know how. :/

[MarkCallow]

With the latest El Capitan (10.11.5) and Xcode (7.3.1) none of my environment variables are visible in Xcode even when the auto-start problem is avoided. I can't say which update caused the new breakage as I had not needed any of my environment in Xcode for a while. Unfortunately @xapple's

defaults write com.apple.dt.Xcode UseSanitizedBuildSystemEnvironment -bool NO

didn't help me either. The before and after "environment" displayed by

sudo launchctl procinfo <process_id>

is identical and does not include any of my environment variables from "inherited environment".

@dan-tull, @mgol, even prior to Xcode 7 & El Capitan, osx-env-sync failed to modify $PATH as seen by Xcode. I gave up on that a long time ago^*. It did though make other environment variables visible to Xcode.

^* Since I only need the modified $PATH in an Action build-phase script, my workaround is to set up the action to use a login shell so that the shell reads my environment. The default is /bin/sh which does not read any startup files. I use /bin/bash -l instead.