Problem

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

Also, persisted state is not restored consistently.

Cause

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

• launchd event: inherits launchd mostly blank env, which means no shell env vars
• atom 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)

I venture the creation of the atom command this way is on purpose to work around the lack of env when run from launchd. But please, dear reader, continue on to the next step.

Current workaround / Anti-feature

Manually control Atom 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" OS X way: "Atom.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. wrap Atom.app startup in a login shell (i.e make Atom.app/Contents/MacOS/Atom a script that calls whatever the user shell is† as a login, non-interactive one before calling the real Atom binary), to inherit global env, so that chruby/rbenv/GOPATH/whatever works.
2. make atom command send a signal to Atom.app instead of starting atom itself via Contents/MacOS/Atom. Basically, atom foo/bar has no reason to be different from open -a Atom foo/bar. Precisely, it does not inherit the local environment.
3. 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.

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 Atom and using atom 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

Pet peeve: atom is currently equivalent to atom .. While I can see how this could be ok on other platforms, this is subtly wrong on OS X as atom is expected to be equivalent to open -a Atom, i.e start the app and don't open anything (unless it's set up to open a new document when no document is opened, otherwise merely focus the app, and if the app is not started, start it)

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

Final word

All of this really matters daily when you juggle between projects and makes Atom feel like an unfinished, brittle product, making angry coworkers throwing nails at me for having pushed Atom on them.

† think fish-shell or (god forbid) csh.