[OPEN] How to prevent Atom to update packages at each reload



I have the following problem:

  1. Automatic Atom updates are deactivated

  2. Internet connection is off

  3. Restart Atom to get messages:
    { packages looking to find internet connection to do update check }

I am looking to prevent the Packages to go look for an
update each time Atom is restarted. Reason:

  1. My mobile internet is very expensive and capped.
  2. It makes reloading Atom slow.
  3. Reload happens regularly as I play around with
    making code modules for Atom.

Please - any ideas?
- Dan Padric


I dunno, it might be something that you can’t disable without doing a rebuild of Atom. You could probably tell Windows to not give Atom access to the Internet, but that wouldn’t save time when reloading.


I’m not quite sure where Atom triggers an update check on reload, but there is a 10-minute expiry where Atom will just return the same outdated packages if Atom checks again for updates within that 10 minute period (this does not include manually clicking the “Check for Updates” button, which forces an online check).

Also, opening the Updates panel automatically triggers an update check, so not opening it should reduce the amount of update requests :slightly_smiling_face:.

Sounds like a nice feature to have, though. Maybe the expiry limit can also be extended to an hour or two.



Thank you for contributing to this discussion.

@DamnedScholar : Where do I go && what do I do to make Atom HQ aware of this behaviour?
Maybe I can convince someone to spend time on this sometime in the future.
Or perhaps I can convince someone to teach me:

  1. How to track this behaviour through the code.
  2. How to hack it && contribute to the project.
  3. Alternate - where to find documentation on how to do (1) and (2).

@Wliu: Thank you for making an interesting idea proposal. It has merit if not for one problem:
When executing a reload() [ctrl-shift-f5] the triggering of the update service occurs.
The time you mention is does not come in play when using reload().
To me that means there should be a difference between a code driven reload() vs program restart.

Another thing to consider -
We do not know how the update service works. The mechanism that handles the update for the Atom core
may very well be different than the update service for the packages.

I would not even have noticed this behaviour if there was a way to create a ‘sandbox’ (?) where I could
run Coffeescript code for modules to augment Atom’s functionality. That is… having the ability to
interpret Coffeescript with Atom API from scratch after altering my code.

Import via require({full path: coffeescript file}) works in Atom’s console. But only once.
Atom must reload() before using require({full path: coffeescript file}) again before the
the changed code file is loaded.

I cannot help but wonder -
Is there someone in this community that knows the system well enough && willing to contribute some thoughts?
- Dan Padric


I would be one of those people, having worked on the Updates panel a few months ago :slight_smile:. The package updates system is completely different from Atom’s update system (the former uses apm, the latter uses Squirrel).

Package updates are handled by settings-view. Like I said previously, I don’t know what is causing the update request, but I might be able to add some quick debug statements next week to figure out.



It would be interesting to hear if you make any progress. Thank you for your interest. Please keep me in the loop… just as favour to a curious cat.

I am curious: the timer you spoke of earlier - is the timer’s effect (on apm) still valid when going through a reload?



When you’re proposing a feature for an open-source project, the place to do that is usually the repository for that project.


Thanks for putting this to my attention.


The auto-check on load happens so that the status bar can be populated (https://github.com/atom/settings-view/blob/ea7f18e089fcd4fbcb549aa04dd963437e26f2c0/lib/main.coffee#L70). That currently can’t be disabled short of disabling the status bar package.

You should create an issue requesting a setting to disable automatically searching for package updates.


Thank you for your feedback.
:slight_smile: Having seen your icon on a few packages that I looked through - may I encourage you to keep up the efforts! (thank you!)

I will consider your suggestion (as @DamnedScholar hinted too).

I hope to post a link to the request here when I have done so.

UPDATE: Formal Feature Request


Sorry to re-open this post.

I was hoping to use the function version pinned to resolve this case.
This idea does not seem to block linking to the web.
But there was at least one package I know, that did not ask for a download.
That means the pin function works.

To show where this function is:


The command atom.config.getAll() was run in the console to extract all most of the possible packages. Some active community packages were missed. These were placed in the config.cson file:

    versionPinnedPackages: [
      #AND MORE

Atom was restarted and then updates checked:


If this message comes up, it already fails at how I hoped it to NOT dial the internet.

Then comes the answer back that no updates were found:


It is strange that even with all packages pinned, Atom still phones home. I am curious to know what type of information exchange happen to whom if all packages were pinned.

Late note - Maybe not all packages were captured. Any suggestions on how to use the Atom API to make a list of all installed packages (with or without configuration)



I am going to answer my own question - the Javascript to execute in the console is as follows:
(Put in a text file and formatted to what config.cson requires.)

// create a new editor
atom.workspace.open("packageList.txt").then(successCallback, failureCallback);

function successCallback(_editor) {
  // get all the package names
  _arr = atom.packages.getAvailablePackageNames();
  // package names as string formatted for what CONFIG needs
  _str = '      \"' + _arr.join('\"\r\n      \"') + '\"';
  // write to open text editor

function failureCallback() {
  // if failed

A list of 102 packages could be extracted. This was loaded into config.cson. The result was however what I had before.

So… this idea does not work either.


If it automatically checks in regardless of whether there are any packages that could be updated, then it might be that the change required is inside Atom’s source.

It might be less hassle to try turning off Atom’s ability to access the Internet. It’ll still try to connect, but Windows will stop it.


[No response expected… only feedback given]

@DamnedScholar - The following is a bit off my intended topic theme but I would like to respond to your suggestion.

Firstly - Thank you for your contributions.

Secondly - This is a little bit easier said than done. Allow me to expand.

Details to do with blocking communication by Windows firewall

I have used the TCPView application to snoop which connections are established. Quite a number of node.exe references came up each time an update was triggered. Perhaps even some dependencies phone home too, regardless of the “pinned” state. I did not see any directly named Atom application pop up on the list.

Several versions of node.exe exists through my system. Each Atom version that is on the computer has one - stable and beta. Plus the formal install of node.js. The path of node.exe changes as the Atom version changes. Currently ->


Standard Windows firewall does not allow for wildcards. PLUS there is a flaw in addresses that uses environmental variables (constants): example %windir% should be set as C:\Windows.

To overcome this issue I am trying out the TinyWall application. It has its quirks… you have to tell it what is accepted for connecting to the internet. +++ and my anti-virus is not happy about it.

To the theme - It was my hope to identify a way to make Atom not update anything but not have it complain about it. Checking the internet for an update each time Atom is restarted / reload, feels like a waste. When developing a package, reloading of Atom can happen regularly.



Maybe you could suggest a delay between Atom checking for packages, so that it doesn’t happen every reload but once every half-hour or so?


THAT would be a good idea. @Wliu had something like that in mind to, I think. I have made a formal request already though LINK1 LINK2.

My newest posts here were just testing out a new approach. AND still I wonder why having all packages set to ‘pinned’, the system still dials out. That seems a new issue to raise (read: a new question to ask in a formal way).


I would wager a small amount of money on the reason being the fact that Atom was initially coded to check for package updates, and when someone got around to writing the pinned package setting, they didn’t think about checking whether or not there are packages to update. In this day and age, a little status update check takes so few computational resources that it’s not a mandatory thing for developers to think about when working on non-embedded platforms.


Now you hit the nail squarely.
Coming from the embedded platforms, it drives me crazy to have systems work this way.
AND it is an irritant to wait for Atom look for a non-existing web link to reload when I am offline.
C’est la vie!