Opening Atom from the CLI launches a new instance


When using atom from the command line, it launches another instance of Atom which you can see quickly open and close in the Dock. Is there any reason for this? Other apps that I’ve seen that launch from the command line do so just by bringing the app to the foreground and handling it from there, similar to if you open a file from the Finder.

There also seems to be a noticeable delay when opening something from the command line which makes the app feel slow. I understand this is Beta and if that’s the reason then great! I wanted to bring up the issue though.


Also, for what it’s worth, Mac users can alias the open command to get the same effect:

open -a Atom path/to/file/or/directory

The alias can be alias atom='open -a Atom' and in invoked just like the normal atom command. I’m sure the shell script is doing some extra fun things that are useful but in my daily usage this suits me well.


We went through a lot of iterations of the cli early on. I believe the reason we went with this approach was to allow commands like atom --wait to work and because using open -a Atom wouldn’t send command line arguments to the existing process.

If have a better way I’d love to see a pull request!


OK, so you don’t want to use open -a, but why does the Atom binary take so long to contact the other process? Why does it try to open a new window, which then closes to open the right one? My use case is replacing EDITOR=vi / EDITOR=emacsclient with EDITOR=atom. EDIT: The animations on editor startup are a distracting implementation artifact, and the time taken is a further problem.

I don’t think I’d be qualified to send a pull request for this, I hope somebody else can do it.

I suspect you should just clone (most features of) nailgun (as in, reimplement the code following the features), it would allow solving all the problems you mention (with a minor twist). In other words, the client should:

  • start fast (by, say, being native; you can reuse nailgun’s client)
  • try connecting to the server (that is, the running application) via inter-process comunication (for instance, a local-only network socket)
  • pass the command-line arguments, directory, even environment variables to the server for it to handle; nailgun propagates even standard input/output/error over the connection
  • unlike nailgun, if the server is not available, it should just start it as usual.

Warning: nailgun is not secure, and I’m not sure how to fix that and whether that’s important. Here, in the worst case, another local user might be able to connect to open a file in your Atom instance; if command line actions could perform actions, there would be an actual security risk (imagine somebody giving instructions to another user’s Atom instance). Should that be a problem, I’d look at the Xauth protocol: what I understand is that the client must authenticate to the server with the content of a private file inside ~/.atom, which is filled with unpredictable data at Atom’s startup.


Same problem when opening Atom on Windows, by launching it from the taskbar or to edit a file, il always launches a new instance of it.


@ProbablyCorey I totally forgot about all the CLI options. Great reason for not using open -a. I’ll have to brush up on my shell scripting and try to make a PR.


Another option would be for us to abandon the bourne script and use a node script. This could allow us to avoid having to start another atom process.


Any updates on this? I think Atom is awesome already, but in this particular case it’s pretty slow. When editing commit messages etc. it quickly gets tiring. The editor in general has gotten much quicker after the redact changes, which is great.


@sandstrom If you’re referring to performance, there is a related issue on the repo which you might want to follow.

On this topic of starting a new instance instead of opening the file in the same window, there’s this issue which should be updated once this behavior has been changed.