Set ATOM_HOME in an argument to atom


Is it possible to set the ATOM_HOME variable in an argument to the atom command?

I am trying to use the ‘portable’ version of Atom on Windows (the zipped version) and found that I have to set the ATOM_HOME variable to make it truly portable.

Right now I have created a folder called Atom, which then has two folders, ‘app’ and ‘home’.
I then have an atom.bat file with the following commands in it:

set ATOM_HOME=%~dp0\home

This works fine for opening atom up and then for any file subsequently opened in Atom using open with.
However if I use open with when Atom is not running the ATOM_HOME variable never gets set because it’s just using the Atom exe file and so Atom then tries to use my home directory for it’s ATOM_HOME variable.

This is a problem, so is there a way to pass the ATOM_HOME value in an argument (so I could edit the target of an Atom exe shortcut) or is it possible to set it in the init file for Atom?


You need to set ATOM_HOME so that it is just part of your environment no matter how you start it up. You can set environment variables permanently for your user account by going through the System Properties like in this Stack Overflow question:


I was afraid that would be the answer.

Well until we see a truly portable version of atom for windows I suppose I’ll just stick with the normal installer version so I can at least get the auto updates.

Then I can just copy my .atom folder if I need to to transfer to other computers.

Thank you for your help.


If you want a portable version of Atom because of config syncing, there are also packages that can do this for you, like sync-settings :slight_smile:


It would be nice if folks asking for portability would define a list of requirements for a “truly portable” application. So far it has been something of a moving target.


I suppose most users (certainly in the Windows world, I think), are used to portable apps being contained entirely in one folder (including any settings, configs, packages etc), and that essentially out of the box.

It would be a lot easier if Atom installed to a user-neutral directory, i.e. the other constant gripe people have with the current installation options.


As far as I know, there’s nothing stopping people from setting it up that way with ATOM_HOME. You are right, of course, that it is not that way out-of-the-box.

Wouldn’t a user-neutral directory (I assume you’re meaning like C:\Program Files?) require administrator rights to install, thereby defeating portability?


Yes, true.
So the truly portable thing would be to run Atom without any installation at all.
Of course you’d lose things like automatic addition to PATH, desktop links etc.


For me, truly portable is as already said, the ability to use the program out of the box without it touching anything other than it’s own directory.

In other words, don’t go creating folders and files in other locations so I can just dump the program on a USB drive and use it wherever I want without having to set an ATOM_HOME variable.

It’s nice to have the ATOM_HOME variable but it just feels like a bit of a hack to get things working rather than how it should be.

In my opinion right now the zipped version is a bit backwards in that it by default uses the user directory instead of the current directory that the exe file is it and then you need to spend a while Google’ing how to configure it to not do that.

It would be much more usable if it just used it’s current directory and used the user directory if it was explicitly set somewhere in the settings view.

But I’ve only just started using Atom so I don’t know how the majority feel about that approach and I don’t know how possible it is with the current way it is written.


I’m wondering. Since you launch atom on Windows via a .cmd file, couldn’t you just set the ATOM_HOME variable inside that file, right before the call to the executable?

Of course that only works until the next release comes out, when the .cmd file gets overwritten again. But where auto-updating is disabled somehow, this should work pretty well.


and that’s exactly what breaks the definition of ‘truly portable’. Truly portable means no system configuration is required whatsoever, everything is contained in one app folder.
A cherry on top would be for the portable app to also allow enabling AND removing system integration (like shell integration with context menus/file associations etc.) for those cases when portable install location is guaranteed to not change paths (e.g. running from a local dropbox folder rather than from a USB).

I’m surprised there is confusion re. the definition of ‘portable’ when there are so many portable apps doing that basic thing (e.g. not requiring any config and running out of the box) already.


There have been a lot of changes with regards to Atom’s portability in the last seven months. See this Issue for more details:


Thanks for a prompt response!
Unfortunately, not much has changed regarding this issue despite the seven months that have passed.

In short, Atom still can’t be made portable because it prioritizes system setup over local install. So, if a “portable” install encounters the ATOM_HOME variable on the host system, it’ll disregard the “portable” settings and use those on the host system instead.
Also the sibling folder is a very strange solution, ideally all files should be in one single folder like for all the other portable apps out there.

I’ve already left a comment on another thread I found on this issue ( and also copied it to the thread you linked (

Hopefully it won’t take another 7 months to fix it for this awesome app! :wink:


Pull Requests are always welcome!


I don’t know how to fix the first issue. The second seems like a one-line fix in
But more importantly, both the rule-based system and the sibling folder seem to be conscious developer decisions, so it looks like it’s more about reaching an alignment on what to do.


Honestly, the last definition I heard that most people agreed on was roughly that a portable app should store everything under one folder. This is so that you can just delete the one folder and everything is gone as if the application was never there. According to this definition, the “sibling folder” solution works:

  • Some folder
    • Sub folder 1
      • Atom.exe
      • Other stuff
    • .atom
      • Atom configuration stuff

Delete “Some folder” and :boom: everything is gone, as per the requirements. You can argue about whether ATOM_HOME should be first or not, sure. The rules thing isn’t going to go away … that’s what’s called “graceful degradation”.

We’ve tried several times to implement something that people will agree qualifies as a “portable app”. Every time, someone else comes along and says its wrong for one reason or another. As I said above:

I don’t think it is unreasonable at this point to ask someone who has expertise in building portable applications to help us out :grinning:


The folder structure is a very minor thing, what you laid out can work — of course I can move my Atom folder inside another Atom folder to co-host an .atom folder.

However, please don’t confuse a minor design quirk with failure to meet the core requirement of being a portable app, i.e. being independent from the host system configuration and storing everything where app is. Using host config files instead of the portable ones (if the host has env var) or writing to the host system (as I’ve read Atom does in AppData/Roaming) clearly breaks that.
I’m very puzzled by where the confusion is coming from. In those several threads I haven’t seen anyone arguing that it’s ok for a portable app to change the host system. I mean even Wikipedia is crystal-clear on this (PortableAppWiki).
So it’s a bit unreasonable to seek expertise on such a simple conceptual issue.

Now, specific implementation may theoretically benefit from such expertise, although practically it’s already figured out (one of the solutions is already stated in the TODO list in the github thread).


I’ve read this thread. I agree that the current solution for a “portable” is good. The current suggested solution separates the binary application from the user data ("~/.atom").
I also agree with the suggestion of this thread topic, an argument to atom should take first priority over a system variable. I would like to see a command line option added. Or i’ll just add my opinion that having ATOM_HOME be the #1 priority preference is a mistake because the assumption is the user can modify the environment. Default behavior, #1 priority should be a command line switch or local file setting. The system should not control the app. This can be a security issue.
Thanks to the team for discussing the Atom design.


Sharing the latest update to the Atom Flight Manual portable mode.