vscode: Cannot search for or access extensions when extensions are enabled

  • VSCode Version: 1.40.0
  • OS Version: Ubuntu 16.04

Steps to Reproduce:

  1. Uninstall vscode, delete ~/.vscode/ and ~/.config/Code
  2. Fresh reinstall
  3. Ctrl+Shift+X to access Extensions panel
  4. Clock icon appears on extensions logo, endless loading bar above “Search Extensions in Marketplace” box, upon typing anything the whole panel is blank.

Screenshot from 2019-11-09 09-00-18

Does this issue occur when all extensions are disabled?: Yes/No

Bizarrely, no. If I launch with code --disable-extensions the extensions panel search works as intended, and installing extensions appears to work. However keep in mind I have deleted ~/.vscode/ entirely so it is not a third-party extension causing this.

Any help would be appreciated.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 4
  • Comments: 25 (9 by maintainers)

Most upvoted comments

Same problem here, using the latest versions of Code on Ubuntu installed via both Snap and the official deb package. I think I found part of the cause and a workaround.

Try starting vscode one of these two ways to fix the problem:

  • ELECTRON_RUN_AS_NODE=1 code
  • /usr/share/code/bin/code (instead of just code) which sets this for you, if you installed from deb

The point is, ELECTRON_RUN_AS_NODE needs to be set, which is handled automatically by the /usr/share/code/bin/code script but not by the root /usr/share/code/code binary. I have no idea if this is by design or part of a deeper bug, but it seems to fix the problem.

Additionally, it appears that the .desktop files provided by both the snap and deb packages are corrupt in some way. When I launch vscode from the Ubuntu launcher, it takes a long time to start, and extensions never load as described in this issue.

This is the command run by the desktop file for deb for instance: /usr/share/code/code --no-sandbox --unity-launch

There’s at least two problems here. The first, as mentioned above, is that it’s calling the wrong binary and not setting the necessary env var. The second is that the --no-sandbox argument is invalid according to the CLI. Not sure if this contributes to the issue or not.

@sandy081 there is a command:

image

You need to open developer tools to see the output, e.g.:

image

OP here, sorry I have been MIA. I will post logs from my end if needed, but I can confirm opening with --user-data-dir <path_to_new_dir> with some arbitrary empty directory fixes the problem for me (see picture). I can also say that, like @ajsharp I used the Settings Sync extension to sync settings across machines so perhaps this is the root of the problem somehow.

Screenshot from 2019-11-16 09-42-29

Still broken without that launch option however.