Package Details: visual-studio-code-bin 1.39.2-1

Git Clone URL: (read-only)
Package Base: visual-studio-code-bin
Description: Visual Studio Code (vscode): Editor for building and debugging modern web and cloud applications (official binary version)
Upstream URL:
Licenses: custom: commercial
Conflicts: code
Provides: code
Submitter: dcelasun
Maintainer: dcelasun
Last Packager: dcelasun
Votes: 855
Popularity: 12.888280
First Submitted: 2017-12-18 19:14
Last Updated: 2019-10-16 06:35

Pinned Comments

dcelasun commented on 2017-11-15 06:20

FREQUENTLY ASKED QUESTIONS (read before flagging or commenting!)

  • What is the difference between this package and the one in the community repo?

This is the official binary distribution from Microsoft. The one in the community repo is an unofficial build made from source. Beyond the license difference and branding, there are some proprietary features not available in the open source version.

  • There is a new version out, why is the package not updated?

Please check this page before flagging as out-of-date. If there is no new version on that page, it's not yet released. A tag on Github is NOT a release! If you can see the new version on the updates page but the AUR package is still not updated, flag it and give it time. It's usually done within a day or two.

  • I'm using an AUR helper (yay, yaourt etc.) and I can't install it. Why?

Sometimes AUR helpers do weird things. Download the tarball and install it manually with makepkg -si. If that works, report the problem to your AUR helper's upstream, not here.

  • When I install this package xdg-open uses vscode, not my file manager! How do I fix this?

Install shared-mime-info-gnome. Also see this reddit thread.

  • Why is $X a dependency? I don't like it.

Just because $X is not required to open the app, doesn't mean there is nothing that depends on it. Always search the comment history on AUR to see if that dependency has been previously discussed before writing your own comment. Still nothing? Then use namcap to make sure it's really not needed. If namcap doesn't complain, please leave a comment here and I'll investigate.

  • Something is broken with the app, where do I report it?

The problem might be a packaging issue (wrong paths, dependencies, icons etc), so please write a comment here first. If you don't get a reply, or if someone says it's an upstream issue, you can report it on Github.

  • I have a problem with this package, can I email you?

No, you won't get a reply. Please stop doing this. Leave a comment here instead and be patient.

  • What happened to visual-studio-code?

It got renamed with a -bin suffix. If you have the original package installed, you will be prompted to delete it when you install this package for the first time.

Latest Comments

1 2 Next › Last »

eschwartz commented on 2019-10-13 05:11


You're doing G-d's work. :D Thanks for helping to get us one step closer to a world in which people no longer use the which program.

jplatte commented on 2019-10-08 18:39

Seems like the which dependency will be removed in the next release :)

jplatte commented on 2019-10-08 12:09

I opened a PR to get rid of the which dependency:

dcelasun commented on 2019-10-08 08:12

@farseerfc good point! I've updated this package and visual-studio-code-insiders.

farseerfc commented on 2019-10-08 08:04

@dcelasun which is in base-devel which means that is assumed to be installed where makepkg is run. But we cannot safely assume the machine/environment runs makepkg is the same machine/environment that installs the package. In other words, base-devel is assumed to be in the makedepends array of all AUR packages, but not the depends array. If a program needs something from base-devel in runtime, I think that package should be added to depends.

akiirui commented on 2019-10-07 10:08


Oh, which is indeed in base-devel. maybe because base package replace, which and some packages marked unused packages (orphans) by pacman -Qdt... ( and I uninstalled these...

I think I need reinstall base-devel Please ignore my previous comment (XD

dcelasun commented on 2019-10-07 07:29

@akiirui, which is in the base-devel group which is assumed to be installed by all AUR packages.

rsplayer commented on 2019-09-28 13:03

There is somrthing that wasn't noted in arch wiki is that the "code" default Community repo can't run bash profile commands. When I installed NVM and then installed nodejs with it, node and npm commands can't be run in tasks.json or launch.json, you can only run those commands in integrated terminal. Although, this official visual code build runs those commands in tasks and launch.json without problems.

If you use NVM, flutter... I recommend you to use this package.

electricprism commented on 2019-09-17 18:43

Seems like more people should know this bin package tracks their telemetry and sends it back to Microsoft.

To remove that caveat people should us vscodium-bin

Just learned this myself and am switching away.

dcelasun commented on 2019-08-29 12:45

@brainplot thanks for letting me know. Looks like Electron has already set the default to gio, so I've replaced gvfs dependency with glib2 (which provides gio). Anyone wishing to use other thrash implementations can set ELECTRON_THRASH environment variable as described in the wiki.

brainplot commented on 2019-08-29 12:20

The gvfs optional dependency should be removed. As per the wiki (, Electron doesn't necessarily need gvfs to move files to the Trash. An environment variable needs to be set to tell Electron which program to use.

dcelasun commented on 2019-08-03 20:11

@dehein binutils is in the base-devel group which is mandatory for installing AUR packages. Quoting from the wiki:

Packages in the AUR assume that the base-devel group is installed, i.e. they do not list the group's members as dependencies explicitly.

dehein commented on 2019-08-03 20:03

Please add binutils as dependency

atoms commented on 2019-07-04 13:28

if you want to use docker plugin on kde you need to install gnome-keyring, i suppose it should be also added to dependencies. as it cannot save secrets without it.

dcelasun commented on 2019-07-03 19:28

I've just pushed 1.36.0 with Electron 4, which doesn't support 32 bit Linux so I've removed it from this package as well. Users on 32 bit systems should stay on the previous version.

dcelasun commented on 2019-06-19 20:59

I'm on Gnome as well and I don't have this behaviour you are describing. Still, see this reddit thread for a solution.

By the way, this is upstream behaviour, not something specific to the Arch package.

EDIT: I've updated the stickied FAQ with this information.

asermax commented on 2019-06-19 20:54

It doesn't purposefuly try to hijack it, but it does as a side effect of setting it's support for inode/directory. Most editors do support opening folders as well but don't declare it on their .desktop files; so far this has been the only case I have had this happen with an editor (I did have a similar issue when installing multiple file managers though). Also, I did try to use xdg-open (which is DE independent afaik) to make sure it wasn't a gnome specific issue or had something to do with my own configuration before checking the .desktop file and coming here to check if it was a known issue. You own the package so feel free to keep it as it is, just be aware this same issue could happen to more people.

dcelasun commented on 2019-06-19 20:36

This package doesn't hijack anything. Visual Studio Code can open directories, so the desktop file declares support for it. If your desktop environment makes that the default, there should be a way to change it. If there isn't, that's a problem with that DE, not this package.

asermax commented on 2019-06-19 20:34

Like @noirscape mentioned, this package is hijacking the inode/directory mimetype; the .desktop file provided with the package explicitly sets itself as the application to open folders, which I assume is something most users don't want.

noirscape commented on 2019-06-17 20:28

Not entirely sure why this is happening, but for some reason the package ends up prioritizing itself for inode/directory for me, which causes things related to xdg-open to use VS Code.

While I can change it manually back each time by editing the relevant line in /usr/share/applications/mimeinfo.cache, it would be handy if there's some sort of way to repair it without having to do that on each update.

dcelasun commented on 2019-06-07 12:33

@Gonzalo2683 you can use the same process. Download the package, extract it and install with makepkg -si.

Gonzalo2683 commented on 2019-06-07 12:32

I'm new to arch, I've installed the previous version of visual studio code with the command makepkg -s, how do I update to the latest version?

mmcoding commented on 2019-06-06 00:45

I'm using deepin and still the old logo

jolan commented on 2019-06-05 22:14

@dcelasun Ah ok, thanks for updating it, I do happen to use xfce.

jolan commented on 2019-06-05 22:14

@dcelasun Ah ok, thanks for updating it, I do happen to use xfce.

dcelasun commented on 2019-06-05 21:35

@jolan thanks, fixed. Note that code.png is only used as a workaround for an Xfce bug. Other DEs get the icon from upstream.

jolan commented on 2019-06-05 21:29

FYI, the icon was changed but code.png wasn't updated.

francoism90 commented on 2019-06-04 18:30

Spam is being posted a lot nowadays, maybe the devs should add something like re-captcha. :|

Anonymous comment on 2019-05-27 11:40

wow good information provide this post. happy best post. -> -> -> ->

manuelino commented on 2019-05-17 07:18

@dcelasun Works! The icon is back on the desktop.

dcelasun commented on 2019-05-17 06:58

@manuelino should be fixed now.

manuelino commented on 2019-05-17 06:52


Thanks for the workaround, but as is it does not work, because the image under hicolor is named "code.png", while the desktop entry refers to it as "visual-studio-code".

Simply renaming the image and updating the icon cache sorts it out. Also, the image has executable bits set (0755 rather than 0644).

dcelasun commented on 2019-05-16 21:26

@manuelino I've added a workaround, please try with the latest version and report back.

manuelino commented on 2019-05-03 08:32

@dcelasun Here is the link to the issue:

dcelasun commented on 2019-05-02 20:13

@manuelino, can you link me to that issue? I wouldn't resize it at build time (it would require a dependency), but I'd be willing to ship a static image with the PKGBUILD.

manuelino commented on 2019-05-02 14:24

It seems that there is a bug in the current XFCE packages, which causes desktop launchers not to display icons if they are placed under /usr/share/icons and not under a theme. It also breaks if moving the icon under the hicolor theme but under a 1024x1024 directory.

Is there any chance the icon could be resized at build time to 512x512 and installed under the hicolor theme? I understand this is really an issue with the DE (I have reported this to the devs), but this packages is the only one I have seen in a while that does not store the icons under the hicolor theme and that has such a large image.

If this looks feasible, I am willing to provide a patch. Since the proposed path is standardized by the Icon Theme Specification, it should have no negative impact on other DE's.

saverio commented on 2019-04-22 17:57

@cogwerkz Many thanks... I didn't read the FREQUENTLY ASKED QUESTIONS at the top. The FAQ is very useful and it must be red by all users before posting repetitive comments, sorry it was my issue.

cogwerkz commented on 2019-04-21 18:36

@saverio The one in the Community repo is the fully open source version, meaning it only has the open source base, and hasn't got direct access to proprietary elements like the marketplace.

This version has a commercial license, which is something you'll never see on anything in the official repos.

saverio commented on 2019-04-21 18:02

Hi dcelasun, is there any difference between this AUR maintained package and the one available in the official Arch Community repo? (

As far as I can see, both Community and your AUR package have the same version...

Rainer commented on 2019-04-07 10:02

I'm on arch 32Bit. I downloaded the snapshot and installed the package with makepkg -sirc. Everything worked fine. If I start either from the menu or with "code" from the terminal it starts but all I get is a blank screen. Did I missed something?

elgs commented on 2019-04-04 20:24

1.33.0-2 works! Thanks @dcelasun.

dcelasun commented on 2019-04-04 20:22

Sorry, fixed.

elgs commented on 2019-04-04 20:20

:: Searching databases for updates...
:: Searching AUR for updates...
:: 1 Packages to upgrade.
1  aur/visual-studio-code-bin  1.32.3-1 -> 1.33.0-1
==> Packages to not upgrade: (eg: 1 2 3, 1-3, ^4 or repo name)

install: cannot stat '/home/elgs/.cache/yay/visual-studio-code-bin/src/VSCode-linux-x64/resources/app/LICENSE.txt': No such file or directory
==> ERROR: A failure occurred in package().
Error making: visual-studio-code-bin

dcelasun commented on 2019-04-04 13:19

@melkopisi, @HerHde, there are plenty of solutions to this problem, all of them a quick search away. For example:

There should be more for other DEs as well.

HerHde commented on 2019-04-04 12:59

Well, about the "inode/directory" link: It interferes with almost every software on my freshly installed system (Manjaro), including Nautilus and Firefox.

melkopisi commented on 2019-04-03 20:21

butother apps suggest open their file in visual studio code instead from nautilus like Android studio because it has the priority above nautilus to open folders

any idea how to fix this?

dcelasun commented on 2019-04-03 12:53

@melkopsi, that's needed for opening directories with VS Code. If it interferes with Nautilus, that must be a configuration issue on your end. It works fine for me here.

melkopisi commented on 2019-04-03 12:21

Please can you stop adding "inode/directory" to the MimeType because it interferes with nautilus?

dcelasun commented on 2019-03-22 20:50

@albertvaka that has been asked and answered several times, read the comments please.

albertvaka commented on 2019-03-22 20:49

Why is this package needed now that "code" is in the main repo?

dcelasun commented on 2019-03-11 08:34

@davidmcinnis, that URL does exist. It works fine for me.

FernandoBasso commented on 2019-02-22 21:46

Hash problem seems to be gone now. Just removed the old download and aurget installed vscode just fine.

Thanks to @dcelasun for reporting upstream.

dcelasun commented on 2019-02-13 13:27

I've reported it upstream:

xereda commented on 2019-02-13 13:23

And what do we do?

dcelasun commented on 2019-02-13 12:57

@pedromello, thanks for the confirmation. The hash I'm getting from both the Netherlands and UK is 154a316eb6785c126e2fccd80a5c76291321ca2d6945e7a2a13f2e262be89bde. Can someone else from a different country check as well?

EDIT: Checked from USA and Turkey as well, both get the above hash. I'm guessing this is a Latin American mirror issue.

pedromello commented on 2019-02-13 12:51

I've got the same hash as @xereda 39e953dc16f248399d286cdca1653345ff32927affc0256ea4a62607f8f5f232 code_x64_1.31.1.tar.gz

I've noticed both me and @xereda are from Brazil (based on the language of the yay output in his post). I this case, @dcelasun hint about a mirror with a different version is valid... and annoying at the same time :)

dcelasun commented on 2019-02-13 12:22

OK first of all, please don't make multiple comments in succession. Just make one and edit it if necessary.

Secondly, please try without yay (see the stickied FAQ comment, just use makepkg -si). If that still doesn't work, my guess is the mirror you are downloading from has either a corrupted tarball or simply a different version.

dcelasun commented on 2019-02-13 12:00

@xereda, something must have gone wrong with your download which corrupted the file. Delete it and try again.

$ sha256sum code_x64_1.31.1.tar.gz 
154a316eb6785c126e2fccd80a5c76291321ca2d6945e7a2a13f2e262be89bde  code_x64_1.31.1.tar.gz

munim commented on 2019-02-10 18:35

Getting the following error while upgrading from 1.30.2-1 -> 1.31.0-2

(OK):download completed.
mv: cannot stat '/tmp/yaourt-tmp-munim/aur-visual-studio-code-bin/stable': No such file or directory
  -> Found visual-studio-code.desktop
  -> Found visual-studio-code-url-handler.desktop
==> Validating source_x86_64 files with sha256sums...
    code_x64_1.31.0.tar.gz ... NOT FOUND
    visual-studio-code.desktop ... Passed
    visual-studio-code-url-handler.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Makepkg was unable to build visual-studio-code-bin.
==> Restart building visual-studio-code-bin ? [y/N]

DonJogi commented on 2019-02-07 20:24

@dcelasun thanks for your suggestion! I wanted to try this right now, but the new version 1.31.0-2 works great, so it's solved for me. Thanks again!

chih commented on 2019-02-07 04:20 In 1.31.0. gconf no longer needs.

dcelasun commented on 2019-02-05 09:55

@Donjogi, can you try code --disable-gpu and see if it helps?

DonJogi commented on 2019-02-04 19:05

I tried to install visual-studio-code-bin today freshly with yay on KDE Plasma 5.14.5. On startup the app crashes before showing a window with the following stacktrace. I double-checked the current "code" arch package which works out of the box.

Any hint if I can solve this by myself?

$ code --verbose
[21302:0204/] InitializeSandbox() called with multiple threads in process gpu-process. [main 7:41:14 PM] Sending env to running instance... [main 7:41:14 PM] [ 'TypeError: Cannot read property \'call\' of undefined', ' at e.onPromise (/opt/visual-studio-code/resources/app/out/vs/code/electron-main/main.js:191:666)', ' at e.onRawMessage (/opt/visual-studio-code/resources/app/out/vs/code/electron-main/main.js:191:326)', ' at /opt/visual-studio-code/resources/app/out/vs/code/electron-main/main.js:190:769', ' at (/opt/visual-studio-code/resources/app/out/vs/code/electron-main/main.js:123:512)', ' at a (/opt/visual-studio-code/resources/app/out/vs/code/electron-main/main.js:200:948)', ' at Socket._socketDataListener (/opt/visual-studio-code/resources/app/out/vs/code/electron-main/main.js:201:153)', ' at emitOne (events.js:116:13)', ' at Socket.emit (events.js:211:7)', ' at addChunk (_stream_readable.js:263:12)', ' at readableAddChunk (_stream_readable.js:250:11)', ' at Socket.Readable.push (_stream_readable.js:208:10)', ' at Pipe.onread (net.js:594:20)' ]

angellusmortis commented on 2019-02-01 05:39

@noraj code is maintained by the Arch team. It is them taking the VS Code code base and building their own open source version. It is technically an unoffical release of VS Code.

visual-studio-code-bin is the official release by Microsoft repacked to be installed on Arch.

There are advantages and disadvantages to both of them. Most notably, code is open source and visual-studio-code-bin has many of Microsoft's closed source improvements (it works via X11 forwarding for example, whereas most other Electron apps do not).

(at least that is my take on why there would be interest in this one)

noraj commented on 2019-01-22 10:06

Now that there is, what is the interest of visual-studio-code-bin ?

enihcam commented on 2018-12-29 00:04 Finally gconf will be dropped in next version.

dcelasun commented on 2018-12-15 18:20

OK, I've restored StartupWMClass.

Anty0 commented on 2018-12-15 16:34

@dcelasun I agree with @jgierer12.

I haven't been using VS Code for a long time, so my advice for @nix6839 was more in general manner, but after looking into it more I don't think this is upstream issue.

jgierer12 commented on 2018-12-15 16:22

Hi @dcelasun, I don't think this is an upstream issue. The PR you linked removed the StartupWMClass from visual-studio-code-url-handler.desktop, but not from visual-studio-code.desktop. I'm having the same issue as @nix6839 and was also able to fix it by re-adding StartupWMClass=code into the latter file.

nix6839 commented on 2018-12-15 14:45

@Anty0 I'm not fixed that way either.

nix6839 commented on 2018-12-15 14:44

@dcelasun I hope to put it in visual-studio-code.desktop. (Ref to and

Anty0 commented on 2018-12-15 11:20

@nix6839 Try re-add (remove it and add it again) VS Code to your favorites. You probably have added wrong one (the one which was starting before fix).

dcelasun commented on 2018-12-15 08:33

@nix6839, since that was done on purpose, you should report it upstream.

nix6839 commented on 2018-12-15 04:07

Please re-add "StartupWMClass". Without it, an error occurs. The error is as follows the dock contains multiple copies of the same icon.

dcelasun commented on 2018-12-14 16:55

@teohhanhui, thanks for the heads up. This should be working now, e.g xdg-open vscode://file/etc/pacman.conf or xdg-open vscode-insiders://file/etc/pacman.conf for the insiders build.

teohhanhui commented on 2018-12-14 16:29

Please add the code-url-handler.desktop file (visual-studio-code-url-handler.desktop in our case) to support vscode:// URIs. See and

matfantinel commented on 2018-12-08 19:28

I'm on Manjaro Deepin, and VS Code cannot access my system-wide $PATH variable. I am not being able to properly debug .net core apps because of that.

On VS Code, "echo $PATH" prints:


Which seems to be a default configuration, but doesn't update if I set $PATH outside of it. If I set the variable inside VS Code Terminal, it will reset after restart.

I've noticed this behavior in the Flatpak version of VS Code in Linux Mint once. In that case, installing from the website worked.

shastry commented on 2018-11-28 05:37

For delete to trash to work, this environment variable needs to be set: ELECTRON_TRASH=gio

(or trash-cli, kioclient5, kioclient)

zetxx commented on 2018-11-27 09:01

there is new code version build specially for the flatmap-stream

ckolos commented on 2018-11-26 22:57

version 1.29.1 uses/installs flatmap-stream 0.1.1 for the references-view extension.

If you have installed this package, you should read over and determine if you are affected or not.

dcelasun commented on 2018-11-03 19:34

All right, thanks for voicing your opinions everyone. I've decided to remove pylint as an optdepend in the next version. I also won't be adding any language specific dependencies from now on.

jakebailey commented on 2018-11-03 19:25

IMO, pylint is an optional dependency for an extension you can install, not for the editor itself, so it probably shouldn't be an optdepend. Optional dependencies for things like trash support definitely make sense because it's an optional editor feature, but I can think of a number of other extensions that also ask for things to be installed (the Go extension prompts to install linters, C/C++ extension asks about clang-format, etc), and I wouldn't personally want those added as optdepends either. If you configure the extension to specify a different linter (flake8/pep8), then it'll show the same prompt but for that other tool too, pylint's just the default. Always running pylint is going to stop being the default in the python extension anyway [1] [2].



(Disclaimer, I work on the python team at Microsoft, but this isn't any sort of official opinion or anything. I just noticed the added dep during an update on my personal machine.)

Anty0 commented on 2018-10-30 16:31

And of course all of this is just my opinion, so feel free to change my mind, if you know something I don't. :)

Anty0 commented on 2018-10-30 16:27

*But only packages, that can be used by that package without any plugins. (= If visual studio code does not support python without additional plugin, python-pylint should not be added as optdependcy, but if visual studio code support python by default and opening python file shows that warning without installing additional plugin, we should add python-pylint as optdependcy.)

Anty0 commented on 2018-10-30 16:20

@elgs I think, that optdepends are not about what you want, but about what you may want. So they should contain packages, that can be for someone only "pollution".

Personally, I think, that in optdepends should be every package, which can be used by that package in any way. Also sometimes it is good idea to add as optdependcy package, that is not used by that package, but can make usage of that package significantly easier. (There are lot of examples of that in official Arch Linux packages.)

elgs commented on 2018-10-30 03:47

Personally, I don't mind if there is a ton of optdepends.

I know you don't mind. But other people may see it as pollution. Many people don't like anything which is not necessary for them.

Caldazar commented on 2018-10-30 00:56

Fair point. You can't just add a ton of optdepends for every eventuality; you need to draw a line somewhere.

I see two main criteria, each of which is a good reason for an optdepends:

  1. The package is essential for a basic core functionality ( here 'basic Python support'. VSC complains about this package missing, not about 'pyflakes' )

  2. The package is arguably supposed to be installed --asdeps. If there is no package to optdepend on it, then it becomes an orphan as far as Pacman is concerned.

Both rules apply here imo. You could even make a point for XDebug for PHP even though VSC doesn't complain about that one. QtCreator for example has even git, mercury, valgrind etc. as optdepends.

If it gets too much, as it might happen with multi-language editors, then that's rather an argument for splitting the package into multiple optimized ones, like with Eclipse and Netbeans, not for letting the user whack-an-error-message.

Personally, I don't mind if there is a ton of optdepends. Let me know on install what else might be useful in combination with the main package.

elgs commented on 2018-10-29 21:46

I also think adding python specific things as dependency (even optional) is a bad idea.

TheAifam5 commented on 2018-10-29 21:32

@Caldazar that's a really bad idea.. VSCode has nothing with Python. So let's add Java, dotnet, and all other languages as a optional dependency -.- That's also does not change anything, so I wonder why that should be a optional dependency. There is also other python linter: pyflakes.

Caldazar commented on 2018-10-27 22:16

Could you please add 'python-pylint' as an optional depenendcy ( python-pylint: Code analysis for Python )?

As soon as I opened a *.py file, VSC complained "Linter pylint is not installed" and tried to make me install it via pip. It seems to consider it as a must-have for python language support.

I installed it explicitly with pacman but I'd rather have it --asdeps for VSC.

Nowaker commented on 2018-10-18 18:24

Please change the description in PKGBUILD to:

pkgdesc="Visual Studio Code (vscode): Editor for building and debugging modern web and cloud applications (official binary version)"

This will make searching way easier. Thanks.

Xorg commented on 2018-10-13 07:16

@daveshaheen: Thank you for your trick!

daveshaheen commented on 2018-10-13 00:41

Another option instead of modifying /etc/makepkg.conf is to create a ~/.curlrc file with the line --http1.1

Tairosonloa commented on 2018-10-11 16:49

It fails when it tries to download v 1.28.0 from (I'm using pacaur)

However, I could manually download the tar.gz from the above link, insert it on the pacaur cache folder, and the installation was successfully.

dcelasun commented on 2018-10-11 06:08

@tavuntu, It's the lines starting with http::/usr/bin/curl and https::/usr/bin/curl in the DLAGENTS array in /etc/makepkg.conf.

tavuntu commented on 2018-10-11 03:16

@dcelasun which line do I add that flag in?

dcelasun commented on 2018-10-09 06:57

@Chipsterjulien as a temporary workaround, you can edit DLAGENTS in /etc/makepkg.conf and add --http1.1 to the curl command.

Chipsterjulien commented on 2018-10-09 06:52

Unable to download file:

-> Téléchargement de code_x64_1.28.0.tar.gz… % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 130 100 130 0 0 84 0 0:00:01 0:00:01 --:--:-- 84 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0 curl: (16) Error in the HTTP2 framing layer ==> ERREUR : Erreur lors du téléchargement de

dcelasun commented on 2018-09-18 14:14

@ghotrix, that's a network on your end. I can download the tarball just fine.

ghotrix commented on 2018-09-18 12:35

OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to while trying to install. Does anyone also experienced such an error?

dcelasun commented on 2018-09-13 16:14

@pascenio, update your whole system first (pacman -Syu) before updating this one.

pascencio commented on 2018-09-13 16:11

Hi guys!

I'm trying to update this package but get the following error:

error: the operation could not be prepared (the dependencies could not be satisfied) :: lib32-glibc: installing «glibc» (2.28-4) dependence breaks with «glibc=2.26»

Do you have some workaround for this issue?

dcelasun commented on 2018-09-12 09:57

@loodoons sorry, no idea. You might try asking on Github.

loodoons commented on 2018-09-12 07:53

@dcelasun You're right. It was a GPU issue. Your answer fixed my problem.

Do you know why I've got this issue?
I've installed all the intel graphic drivers.

dcelasun commented on 2018-09-12 05:42

@loodoons, I can't reproduce the problem. The cli and .desktop launchers are meant to be separate, there have been many problems in the past when using the same one for both cases.

The issue you are seeing sounds like a gpu problem. Can you try replacing:

Exec=/opt/visual-studio-code/code %f


Exec=/opt/visual-studio-code/code --disable-gpu %f

and see if that fixes it?

loodoons commented on 2018-09-11 20:07

I found a bug that is annoying. When you drag and drop inside the user
interface, Code freeze. There's nothing in the log. This bug only occur when you launch the software with the .desktop file.
So I found a fix.

Just edit this file /usr/share/applications/visual-studio-code.desktop and replace this line

Exec=/opt/visual-studio-code/code %f


Exec=/opt/visual-studio-code/bin/code %f

I think there's missing many env var when you launch Code from /opt/visual-studio-code. Can you apply the fix in the package?

Thank you very much,
Guillaume Quittet

axionl commented on 2018-09-11 00:27

The Conflicts package should be changed to 'code'?

dcelasun commented on 2018-09-07 05:44

@Visione sure, will do so at the next version.

dogumon commented on 2018-09-07 05:09

1.27.1 is out now

Visione commented on 2018-09-06 15:31

@dcelasun great work, thanks!

Have you thought about including libdbusmenu-glib as an optional dependency? It allows vs code to pass the menu through DBus, makes KDE global menu work.

stepovic commented on 2018-09-06 14:05

@adlerdias: Seems to be a Windows-only bug as stated here:

Nevertheless 1.27.1 is expected to be released pretty soon.

adlerdias commented on 2018-09-06 13:23

The package has been marked as outdated, but the maintainer must wait until 1.27.1 because of the bug:

halopro77 commented on 2018-09-02 04:03

Bug: Dragging files and other draggable items causes complete lock Posted a bug in detail on

Quick Note: this bug only happens when running code from /opt/visual-studio-code/code, and not the ones in /opt/visual-studio-code/bin/code and /usr/bin/code

Not 100% sure if this is a pkgbuild issue or not as I'm not too versed in pkgbuilds (not sure why there are two binaries in the first place?)

dcelasun commented on 2018-08-22 12:19

@clockface, if I understand that thread correctly, this affects a single key combination and the workaround is non trivial: It introduces a new dependency and even then it doesn't work for everyone. GTK 3.24 is scheduled for release in September, so I'd rather wait a few weeks for that.

But if you or anyone else can come up with a simple, non-invasive patch I'd be happy to take a look.

tonesetter commented on 2018-08-21 22:49

@dcelasun, any plans for a work around to this issue:

until gtk 3.24 is released

dcelasun commented on 2018-08-17 16:20

@LChris314 fixed, thanks!

LChris314 commented on 2018-08-17 16:17

Thanks for the quick update! I suppose the following two lines should be removed from the PKGBUILD?

14 makedepends=(patchelf)
24 noextract=("glibc-2.27-3-${CARCH}.pkg.tar.xz")

dcelasun commented on 2018-08-17 15:50

Updated to 1.26.1, which removes the various glibc workarounds and replaces gtk2 with gtk3.

dcelasun commented on 2018-08-16 21:01

Thanks for the heads up @orangecake. I will wait another 24 hours before reverting the workarounds and give all mirrors time to catch up, so everyone can update without problems.

orangecake commented on 2018-08-16 20:57

glibc 2.28-4 has landed in core. So it seems that all the extra patching logic can be removed. I've been running this without any changes with glibc from testing for quite some days without any issues.

dcelasun commented on 2018-08-16 08:51

@dogumon, are you using a custom launcher? Because I've added the library override to both the official cli launcher (/usr/bin/code) and the .desktop launcher.

dogumon commented on 2018-08-16 08:17

@dcelasun I had to add LD_LIBRARY_PATH=/opt/visual-studio-code/libs to my .desktop file manually (maybe because mine already existed), but otherwise this works fine for me & is much preferable to a manually managed solution. Thank you for updating, glad I could help.

dcelasun commented on 2018-08-16 05:45

@dogumon, thanks for debugging this.

I've pushed a new pkgrel with private copies of libxml2 and icu. File browser is working for me, but please report any issues you see.

dogumon commented on 2018-08-16 00:05

Safe fully-functional workaround for now:

  1. Download previous versions of libxml2 and icu
  2. Extract usr/lib/* contents from archives somewhere (ie. ~/lib_overrides)
  3. Launch code with LD_LIBRARY_PATH=~/lib_overrides code

This works with the current workaround version of this package & requires no system-wide downgrades.

dogumon commented on 2018-08-15 23:27

The issue for me seems to be that while glibc 2.27 is required for electron to not segfault right away, the most recent versions of libxml2 and icu require glibc 2.28 to work properly, which appear to be used for all file browser functionality.
While using the 2.27 workaround, these libraries cause a segfault whenever a file prompt is meant to be displayed.

I had originally tried downgrading all involved packages, and while that made VSCode work again, it however broke my KDE entirely, so I do not recommend it. In case the package maintainer wants to try a workaround (similar to what was done for glibc), these are the packages I downgraded:

  1. glibc and lib32-glibc to 2.27-3
  2. libxml2 to 2.9.8-2
  3. icu to 61.1-1

Again, I do not recommend downgrading these globally as it will break your system.

dcelasun commented on 2018-08-15 05:03

Until this issue is fixed, you might want to try the experimental Electron 3 build.

Dan.Maina commented on 2018-08-15 05:00

Quick workarounds:

  1. Use your file manager to navigate to the folder I need to open on, then drag and drop the folder on to vs code.

  2. Use the command line to navigate to the directory I want to open, then run the command code .

dogumon commented on 2018-08-15 02:58

I'm getting a similar issue. VSCode will crash when trying to bring up any kind of file browser window, ie via File > Open or File > Save. I'm using KDE Plasma if that makes any difference.

Not sure how relevant this is, but I see it while pushing Ctrl+S to bring up the save dialog, immediately before crashing:

[main 8:56:19 PM] windowsService#showSaveDialog 1
(code:2568): Gtk-WARNING **: 20:56:19.087: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /usr/share/icons/Numix/16/status/image-missing.svg: Unable to load image-loading module: /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/ /opt/visual-studio-code/glibc/usr/lib/ version `GLIBC_2.28' not found (required by /usr/lib/ (gdk-pixbuf-error-quark, 5)
Server response: <?xml version="1.0" encoding="UTF-8"

This makes the program pretty much unusable.

welkie commented on 2018-08-15 00:47

I noticed my VS Code was segfaulting when I tried to open it earlier today. I did another update and I got a patch. Then I came here and read about the glibc issue. Everything was fine after the patch.

Until now at least... Now it crashes when I click "Open Folder". I can't get it to run from the command line because it just opens a GUI window right away and control returns to the terminal, but it did say this... I wonder if this means anything:

[mattwelke@mdesklin browser-b2-upload-file-example]$ code --verbose [main 20:46:54] Sending env to running instance... [main 20:46:54] Sent env to running instance. Terminating... [main 20:46:54] Lifecycle#kill() [20468:0814/] Failed to launch GPU process.

dcelasun commented on 2018-08-14 15:56

@edoantonioco, you also need to revert the workaround commit from this package if you want to use the system glibc.

But I still don't understand why it doesn't work for you with the bundled 2.27 glibc. Are you sure you are on 1.26.0-2 of this package?

edoantonioco commented on 2018-08-14 15:46

So I went to one of the FTP servers from pacman mirrorlist and downloaded the required glibc-2.28-4, and then installed it locally.

Visual studio code still doesnt work.

dcelasun commented on 2018-08-14 12:04

@anohigisavay: glibc 2.28-1 is problematic, it breaks electron apps. That's why I have included 2.27 in the PKGBUILD. Either wait for 2.28-4 to hit [core] (which reverts the problematic bits) or use this package with an update system, which should work fine. See previous comments for details.

anohigisavay commented on 2018-08-14 11:34

@viechang: I kinda have the same issue, except GLIBC_2.28 is required by /usr/lib/ (I have built sqlite-replication from AUR to use lxd).

@dcelasun: No, contrarily, it's because the system is too new. These packages are built with glibc-2.28 but the libc provided by your PKGBUILD is 2.27.

dcelasun commented on 2018-08-14 08:08

@bulletmark, nice catch! But no, I won't bother with it since fixed glibc will be in [core] very soon.

bulletmark commented on 2018-08-14 07:19

@dcelasun, I noticed you copied my PKGBUILD except you put back the two _i686 lines which I deleted. If you are going to bother supporting 32 bit then you need to also fix the --set-interpreter line for that case.

swiftscythe commented on 2018-08-14 07:10

Thanks for the quickfix. I want to point out that v1.26.0 is using gtk3 file dialogs. Moreover, namcap says gtk2 is not needed anymore.

dcelasun commented on 2018-08-14 07:00

@viechang: Update your system.

viechang commented on 2018-08-14 06:53

/opt/visual-studio-code/bin/../code: /opt/visual-studio-code/glibc/usr/lib/ version `GLIBC_2.28' not found (required by /usr/lib/

dcelasun commented on 2018-08-14 06:08

The relevant glibc commit in [core] has been reverted. Updating to glibc=2.28-4 will fix it (it's currently in [testing]).

In the meantime, I've pushed a workaround.

elgs commented on 2018-08-14 00:15

@headkase thanks. I was able to download the 1.25.1 into a temp directory and it works.

headkase commented on 2018-08-13 23:49

@elgs to downgrade download the PKGBUILD as normal and then edit it and in the version change 1.26.0 to 1.25.1. Then with MakePkg use the --skipinteg parameter as the PKGBUILD will then download the older version instead of the latest.

elgs commented on 2018-08-13 23:37

@fardog how did you do the downgrade?

ronjouch commented on 2018-08-13 23:03

@dcelasun here's how other AUR packages for Electron-based apps worked around the glibc segfault:



bulletmark commented on 2018-08-13 22:43

Here's a temporary PKGBUILD which patches in a private copy of glibc v2.27 until this bug gets fixed:

fardog commented on 2018-08-13 22:41

I'm experiencing the same issue, segfault on 1.26.0. Downgrading to the previous version 1.25.1 (git sha of aur package repo is 6d42188) has resolved the issue, so this doesn't appear to be due to some other upgraded system package.

fwiw this is happening on the insiders package as well.

smoak commented on 2018-08-13 22:40

@rawkode and @headkase see this issue:

rawkode commented on 2018-08-13 21:49

/usr/bin/code: line 35: 26811 Segmentation fault (core dumped) ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$@"


headkase commented on 2018-08-13 21:47

With 1.26.0-1 I'm getting a segmentation fault on launch. Previous versions worked correctly.

dcelasun commented on 2018-08-04 12:36

@Marcel_K: You are right, despite the commit being much older than 1.25, it's not in the release for some reason. Reverted to gtk2 and bumped pkgver. The insiders release does have gtk3 though.

Marcel_K commented on 2018-08-04 12:31

@kenokabe: Are you sure that is already included in version 1.25.1? I'm asking because I still see a GTK2 file selector and namcap also says (among other things):

visual-studio-code-bin E: Dependency gtk2 detected and not included (libraries ['usr/lib/', 'usr/lib/'] needed in files ['opt/visual-studio-code/code'])
visual-studio-code-bin W: Dependency included and not needed ('gtk3')

kenokabe commented on 2018-08-04 01:39

Dependencies of gtk2 is outdated. As you can see, VSCode shifted from gtk2 to gtk3.

MrArgoNavis commented on 2018-07-30 01:11

On Manjaro Deepin, the dock icon tends to clear itself from the dock, see:

Under the hood, deepin seems to be using some elements inherited from Gnome. This could be related to that.

malathion commented on 2018-06-06 15:47

This package stores lots of stuff in ~/.config/Code/ that doesn't seem to belong in $XDG_CONFIG_HOME.

In particular:

  • Cache/, CachedData/, CachedExtensions/, GPUCache/, logs/ : user-specific cached data should be in $XDG_CACHE_HOME ($HOME/.cache by default)

  • 'Local Storage'/, Backups/, User/workspaceStorage/, Cookies, Cookies-journal, machineid : This looks like stuff that belongs in $XDG_DATA_HOME ($HOME/.local/share by default)

  • storage.json : I'm not sure about this but it smells fishy :P

For a reference, see and and

Anonymous comment on 2018-06-06 08:07

The information you share is very useful. It is closely related to my work and has helped me grow. Thank you!

springer commented on 2018-05-31 18:40

Installing this package changed my xdg default for folders. xdg-open, which is also used by other programs, now opens VS Code for folders instead of my previous default (nautilus).

I don't think a software installation should change defaults. However, I don't know if this is a bug of this package or an upstream bug.

Manually restoring the previous default is possible with: xdg-mime default org.gnome.Nautilus.desktop inode/directory

dcelasun commented on 2018-05-29 07:46

@spacepluk: Fixed, thanks.

spacepluk commented on 2018-05-29 07:38

:: Checking visual-studio-code-bin integrity... ==> ERROR: provides contains invalid characters: ',,'

enihcam commented on 2018-05-20 03:08

As you can see, VSCode shifted from gtk2 to gtk3.

dcelasun commented on 2018-05-17 05:47

@Batou: This package follows upstream. Feel free to use other packages and/or a personal settings.json.

Batou commented on 2018-05-17 00:12

There is a massive amount of "telemetry" or spying going on within this package. Much more so than when you build the VSCode yourself (the code in AUR). I suggest to everyone to add some anti-telemetry preferences to their user settings at the bare minimum. You should also add some domain blocks to your hosts file. One of the options that's also problematic is the automatic update which is set by default. You should definitely not be updating from within this application so disable it.

I've created a short guide here: Maybe the maintainer should create ~/.config/Code/User/settings.json with the above defaults for all new installations?

welkie commented on 2018-05-09 01:34

I'm having a problem when I try to open an ASP.NET Core app. I've never had this problem before. In the bottom right corner I get a notification saying:

Some projects have trouble loading. Please review the output for more details.

There's more in the "show more output", including a stacktrace. This gist ( includes that, along with my versions of "mono" and "msbuild". I didn't have the msbuild package installed yet, but my troubleshooting led me to manually install that to try to solve this. This GitHub issue ( details the error when I reported it.

gururise commented on 2018-05-06 22:57

Using the C# plugin, I keep getting the following error: "The .NET CLI tools cannot be located. .NET Core debugging will not be enabled. Make sure .NET CLI tools are installed and on the path."

How do I resolve this?

Twiki commented on 2018-04-13 14:03

EDIT: I just renamed my "~/.vscode/extensions" directory before changing and then renamed it back, after renaming the newly created one.

@Anty0 I realise that it replaces "visual-studio-code": "Replaces: visual-studio-code". But will the installed extensions be retained. I'm not looking forward to re-installing and re-configuring a lot of extensions. I know where to find my code config file.

Anty0 commented on 2018-04-10 15:02

@Twiki Just install "visual-studio-code-bin", it automatically replaces "visual-studio-code". Or have you got any problem with it?

Twiki commented on 2018-04-10 14:58


Is there a "proper" way to go from "visual-studio-code" to "visual-studio-code-bin". Right now I'm editing the 2 "visual-studio-code" installer files feeding makepkg, but it's a bit cumbersome.

dcelasun commented on 2018-04-07 18:15

@Sanya_M Please search for inode/directory on this link.

amezin commented on 2018-04-07 15:24

Please, remove "inode/directory;" from MimeTypes in the .desktop file. When "inode/directory" is there, Gnome tries to automatically open connected MTP device (phone) in Visual Studio and do other crazy things

igvalor commented on 2018-04-07 10:31

Looks like the problem with unresolved symbol is SOLVED. There was a rogue installation of nwjs in /opt on my system. Removed /opt/nwjs and all work again. My bad. Sorry.

igvalor commented on 2018-04-06 08:59

Just upgraded to 1.22.0-1. /opt/visual-studio-code/bin/../code: symbol lookup error: /opt/visual-studio-code/bin/../code: undefined symbol: _ZN6icu_588ByteSink15GetAppendBufferEiiPciPi

pharra commented on 2018-03-08 06:46

@Alad, @dotfile: no, when I uninstall c++ addons, it doesn't work. And now I use visual-code-git(aur), which works well(also install c++ addons). emmm, It's strange. maybe something broken in dependencies.

dotfile commented on 2018-03-07 22:22

@xaver: thank you!

Alad commented on 2018-03-07 22:16

pharra: if you use the C++ plugin, it might be related. Microsoft has the tendency to mess up that one frequently.

xaver commented on 2018-03-07 21:54


dotfile commented on 2018-03-07 21:52

@pharra, maybe too many installed addons? On my PC vscode with some python addons uses like 250M for python project.

@dcelasun, can you explain why license is commercial? (on github: MIT)

pharra commented on 2018-03-04 15:42

My vscode uses 3G memory when I just edits single file like a.cpp. Could you tell what's wrong with it.

eksea commented on 2018-02-27 06:50

Electron based application will make Arch block. Did this happen on you guys' computer?

dcelasun commented on 2018-02-13 16:02

@Nowaker: Sure, with the next version.

Nowaker commented on 2018-02-13 15:57

Can you please change the description to:

Visual Studio Code: Editor for building and debugging modern web and cloud applications (official binary version) (vscode)

This way pacaur/yaourt -Ss vscode will show this package.

cybercyst commented on 2018-02-12 18:34

I do have gvfs, but get an error about being unable to move a file to trash when I delete it from within visual-studio-code. I don't know if any one else has this experience? Any ideas of what I could do to debug it?

dcelasun commented on 2018-01-16 15:06

@pr0xity: You shouldn't use --force without really making sure you need it. What was the conflict? Did you install another package that provides /usr/bin/code?

pr0xity commented on 2018-01-16 09:56

Is this package broke? suddenly I cant open vscode and the file /urs/bin/code and /usr/share/applicationc/visual-studio-code.desktop is empty.

EDIT: Needed to run the install with --force all good now :)

mardiros commented on 2018-01-08 17:20

I've copy the desktop file to fix the display of the icon in ALT-TAB, and Application icon in the menu bar of Gnome 3

sudo cp /usr/share/applications/visual-studio-code.desktop /usr/share/applications/code.desktop

Otherwise the /usr/share/icons/gnome/256x256/mimetypes/binary.png is used...

cabbage commented on 2018-01-01 10:48

Quick fix here for anyone who is experiencing vscode opening all file path, which is quite annoying. If nautilus is your file manager, just run

xdg-mime default org.gnome.Nautilus.desktop inode/directory

dcelasun commented on 2017-12-22 13:41

If you are suddenly seeing all "open folder" actions in other apps use vscode as your file manager, this is due to the new inode/directory mimetype in the desktop file. On some DEs, it apparently becomes the default the handler (see here for details). To fix it, create or edit /etc/xdg/mimeapps.list and add the following, replacing Nautilus with your preferred file manager:

[Default Applications]

dcelasun commented on 2017-12-22 08:24

@AveryFreeman: Seems to work fine for me.

AveryFreeman commented on 2017-12-22 07:30

I can't seem to get SCM to work with Git, it says there is no Software Control Manager installed. Git is installed on my system. I tried adding "/usr/bin" to git.path in settings, didn't seem to work. Is anyone else having this issue?

Dj_Krip commented on 2017-12-20 11:36

Please update .desktop file in package. Microsoft provided their .desktop file for vscode

MimeType=text/plain;inode/directory; is missing in current version of package.

% cat /usr/share/applications/visual-studio-code.desktop             
[Desktop Entry]
Exec=/opt/visual-studio-code/code %f
Name=Visual Studio Code
Comment=Editor for building and debugging modern web and cloud applications

dcelasun commented on 2017-12-18 19:38

@Alad: I've replied to the deletion request on list.

Alad commented on 2017-12-18 19:04

"Breaking people's updates" is not a valid reason to go against the AUR's packaging guidelines. Please submit a -bin version for this one to be merged to.

SneakySnake commented on 2017-12-16 20:10

For anybody who is launching code through dmenu, rofi, etc.; and vscode just opens a file named code-stdin-whatever:

This is expected behavior, and you are supposed to use the .desktop file for running vscode outside of a terminal [0].

I expressed my thoughts on this on the issue tracker [1], but this might or might not be acted upon.

For now, I just reconfigured my launcher to use .desktop files by default (it's the more common usecase anyway). Maybe you can do the same too.



elgs commented on 2017-12-15 20:23

Works as expected for me as well. Thanks.

dcelasun commented on 2017-12-15 10:10

OK, just pushed another release. Now /usr/bin/code is a symlink to the shell script, but the .desktop file calls the binary. Seems to be working as expected for me.

SneakySnake commented on 2017-12-15 08:21

Would it be possible for code to be a wrapper script that calls the CLI script if we are in a tty, and the binary otherwise?

I'm asking because if we launch the binary from a terminal, it gives the ioctl error message described below, and the process doesn't get detached from the terminal. Not a big deal, but still annoying.

elgs commented on 2017-12-15 07:56

bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell

When I upgraded to the following version, I got the error message above each time I start code:

Version 1.19.0 Commit 816be6780ca8bd0ab80314e11478c48c70d09383 Date 2017-12-14T09:56:48.842Z Shell 1.7.9 Renderer 58.0.3029.110 Node 7.9.0 Architecture x64

dcelasun commented on 2017-12-15 07:06

@aguniyal: It's a packaging issue and it's fixed now. Next time, please read the pinned comment before opening an issue upstream.

agauniyal commented on 2017-12-15 06:49

Opening via dmenu has different behaviour now -

dcelasun commented on 2017-12-11 20:25

@teej: I think you have a corrupted file.

$ sha256sum visual-studio-code.desktop

de88d95db3f55ce58ffd3c229cbde566099384d4f005cf887b00ccaeed605984  visual-studio-code.desktop

teej commented on 2017-12-11 20:13

The latest version has an invalid checksum for the .desktop file. I was able to install it by manually changing the checksum.

Alko89 commented on 2017-11-24 21:57

yup, its OK now...strange, I tried downloading the file three times with the same result

Marcel_K commented on 2017-11-24 21:11

Probably a network error. Just run makepkg again.

Alko89 commented on 2017-11-24 21:04

Does anyone have issues with the latest snapshot? Mine has the site of 0 bytes and tar gives mi an error `tar: This does not look like a tar archive`

dcelasun commented on 2017-11-15 11:32

IIRC there was an effort to bring the open source version into [community] but it was abandoned after realizing it required a lot of patching to make it fit.

wooptoo commented on 2017-11-15 11:27

This pkg should be in community since it's so popular.

dcelasun commented on 2017-11-15 06:20

FREQUENTLY ASKED QUESTIONS (read before flagging or commenting!)

  • What is the difference between this package and the one in the community repo?

This is the official binary distribution from Microsoft. The one in the community repo is an unofficial build made from source. Beyond the license difference and branding, there are some proprietary features not available in the open source version.

  • There is a new version out, why is the package not updated?

Please check this page before flagging as out-of-date. If there is no new version on that page, it's not yet released. A tag on Github is NOT a release! If you can see the new version on the updates page but the AUR package is still not updated, flag it and give it time. It's usually done within a day or two.

  • I'm using an AUR helper (yay, yaourt etc.) and I can't install it. Why?

Sometimes AUR helpers do weird things. Download the tarball and install it manually with makepkg -si. If that works, report the problem to your AUR helper's upstream, not here.

  • When I install this package xdg-open uses vscode, not my file manager! How do I fix this?

Install shared-mime-info-gnome. Also see this reddit thread.

  • Why is $X a dependency? I don't like it.

Just because $X is not required to open the app, doesn't mean there is nothing that depends on it. Always search the comment history on AUR to see if that dependency has been previously discussed before writing your own comment. Still nothing? Then use namcap to make sure it's really not needed. If namcap doesn't complain, please leave a comment here and I'll investigate.

  • Something is broken with the app, where do I report it?

The problem might be a packaging issue (wrong paths, dependencies, icons etc), so please write a comment here first. If you don't get a reply, or if someone says it's an upstream issue, you can report it on Github.

  • I have a problem with this package, can I email you?

No, you won't get a reply. Please stop doing this. Leave a comment here instead and be patient.

  • What happened to visual-studio-code?

It got renamed with a -bin suffix. If you have the original package installed, you will be prompted to delete it when you install this package for the first time.

dcelasun commented on 2017-11-15 06:04

@afzalarsalan: Thanks, moved it back to depends.

afzalarsalan commented on 2017-11-15 04:57

@dcelasun Apparently gconf is now a required dependency as installing vscode without it installed will leave you with

error while loading shared libraries: cannot open shared object file: No such file or directory

dcelasun commented on 2017-11-14 06:24

@enihcam: Because electron (which is included in the package) requries gtk2 (which is not included in the package) to work.

enihcam commented on 2017-11-14 02:08

@db6edr In that case, why do we explicitly specify gtk2 as one of the dependencies?

db6edr commented on 2017-11-13 07:18

Visual Studio Code is Electron app, which in turn uses Chromium for the UI part. So I guess it would be best to have a look there.

enihcam commented on 2017-11-13 06:25

@dcelasun Thanks! Also, do you happen to know if vscode is going to port to gtk3 or not? I'm removing gtk2 and all its apps from my laptop, and vscode is the last blocker.

dcelasun commented on 2017-11-12 22:12

@sistematico: That's just a network error, try again.

sistematico commented on 2017-11-12 22:04

[lucas@majestic ~]:$ LANG=C pacaur -S visual-studio-code
:: Package visual-studio-code not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...

AUR Packages (1) Old Version New Version

aur/visual-studio-code 1.18.0-2

:: Proceed with installation? [Y/n]

:: Retrieving package(s)...
:: Checking visual-studio-code integrity...
==> Making package: visual-studio-code 1.18.0-2 (Sun Nov 12 19:04:03 -03 2017)
==> Retrieving sources...
-> Downloading code_x64_1.18.0.tar.gz...
** Resuming transfer from byte position 64841244
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 148 100 148 0 0 49 0 0:00:03 0:00:03 --:--:-- 44
0 389 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0
curl: (22) The requested URL returned error: 416
==> ERROR: Failure while downloading
:: failed to verify visual-studio-code integrity

dcelasun commented on 2017-11-09 14:07

@enihcam: Please search the comments, gvfs is needed for the "move to trash" functionality. Still, I'll move both to optdepends.

In the future, if you have a concern about the Arch package please report it here before opening an issue upstream. Thanks.

enihcam commented on 2017-11-09 13:43


can you remove dependencies of gconf and gvfs? they are not needed, for details please refer to

jaxmetalmax commented on 2017-10-26 16:42

@PorousSun once you finished running makepkg you run sudo pacman -U yourpackage.tar.xz

PorousSun commented on 2017-10-26 16:28

@Marcel_K I thought makepkg called pacman, how should I update vscode?

Marcel_K commented on 2017-10-26 07:33

Did you forget to run pacman to actually install the package?

PorousSun commented on 2017-10-26 00:22

I just downloaded the recent snapshot and made makepkg PKGBUILD but the version of vscode stays on 1.15.1 and the logo does not change, what am I doing wrong?

dcelasun commented on 2017-09-22 20:54

@NicoHood: You are using the wrong PKGBUILD, please see my comment on Github.

NicoHood commented on 2017-09-22 20:43

I am trying to build vscode from scratch, not from binary. Any help appreciated:

dcelasun commented on 2017-09-15 18:35

@Malganis: That's just a network error. Try again.

Malganis commented on 2017-09-15 18:32

Got this error when building:
==> Retrieving sources...
-> Downloading code_x64_1.16.1.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 148 100 148 0 0 148 0 0:00:01 0:00:01 --:--:-- 80
100 61.1M 100 61.1M 0 0 54513 0 0:19:37 0:19:37 --:--:-- 201k
curl: (56) Unexpected EOF
==> ERROR: Failure while downloading
==> ERROR: Makepkg was unable to build visual-studio-code.

dcelasun commented on 2017-09-04 11:26

When there is a new VS Code version, please check this page [0] before flagging as out-of-date. A tag on Github is NOT a release!


aurgrans commented on 2017-08-17 18:56

I did some research about the ALT+TAB problem which is actually caused by vscode (that's why there's no Gnome bug report about it)

I think vscode doesn't register correctly with X11, where Gnome (the default ALT+TAB, not Alternatetab) gets the list of windows.
That's probably why it works fine using another desktop environment (tested it on KDE and, to check if it's an Arch Linux only problem, Ubuntu 1704's Unity) or using Gnome in wayland mode.

So in my opinion, the best solution for Gnome-X11 users is to use the preinstalled extension Alternatetab and for other desktop environment or Gnome-wayland it should work anyway. To make it work on Gnome-X11 without Alternatetab you can just hope for a vscode update

dcelasun commented on 2017-08-17 15:49

All right, I've readded StartupWMClass since there is now a workaround for Gnome (thanks @aurgrans).

I couldn't find an upstream Gnome bug report about this, but if anyone finds one or files it, please post it here as well.

TamasBarta commented on 2017-08-17 15:35

When I add StartupWMClass=code, nothing breaks on KDE. It is not a problem with the desktop file, but with the DE, I believe.

aurgrans commented on 2017-08-17 15:28

I think I figured out why I don't have the issue not seeing vscode in ALT+TAB.

Have a look at the Gnome extension Alternatetab (which is installed by default if I remember right)

With it enabled and StartupWMClass=Code everything works fine for me

I hope this hint helps solving those problems!

dcelasun commented on 2017-08-17 05:13

@aurgrans: Please read the several comments below yours. Adding StartupWMClass causes a different (and I think worse) problem.

aurgrans commented on 2017-08-17 02:11

Please add StartupWMClass=Code to the .desktop file. Without this line Gnome's Dash to Dock doesn't recognize the window to be vscode. (with StartupWMClass=Code) (without it)

dcelasun commented on 2017-08-16 08:59

No, this package uses the official upstream distribution without any modifications. Someone already asked this in the -oss package [0], I recommend waiting for an answer there.


TamasBarta commented on 2017-08-16 08:56

Any chance to make this use the "electron" package? I don't know what it takes unfortunately.

dcelasun commented on 2017-08-11 22:25

I've tried it [0][1] with the upstream stuff, including renaming things to "code" instead of "visual-studio-code"; it doesn't work. Adding StartupWMClass=code (or Code) makes the icon invisible in alt+tab, removing it causes the app to use a different icon.

I'll investigate more, but if anyone has an idea, it'd be appreciated.


xaver commented on 2017-08-11 21:23

The second icon issue was exactly why it was added in the upstream .desktop file:
Maybe, it would be best to just ship with the upstream file:
This would btw also enable the "New Window" feature in Gnome Shell etc.

dcelasun commented on 2017-08-11 16:59

OK but there is still only 1 vscode icon in that screenshot?

EDIT: Ah sorry, you are talking about the icon theme. @Ladage was talking about a second icon. Different bug maybe?

EDIT 2: I can repro the different icon with alt+tab as well.

L0g4n commented on 2017-08-11 16:57


I use the dash to dock gnome extension and have the setting that the dock does not auto hide and extends to the whole screen. Here's a better screenshot:

You can see the displayed vscode icon is not the same as in the "search" and so does not get covered by the icon pack.

dcelasun commented on 2017-08-11 16:54

@L0g4n: Sorry, I don't understand your second screenshot, I only see one icon? Also, what dock are you using?

I'm using stock Gnome without a dock, so the only places I see running programs are activites & alt-tab, both of which only show a single icon.

L0g4n commented on 2017-08-11 16:51

I can also reproduce this.
Icon is displayed correctly when searching for it in gnome 3:
But when launched and displayed in the dock it looks like this:

dcelasun commented on 2017-08-11 11:56

@Ladage: I can't seem to reproduce it [0], can you share a screenshot?

Ladage commented on 2017-08-11 11:25

Since StartupWMClass=code was removed, a second icon is shown when vscode is launched in Gnome. Adding it back fixes this.

dcelasun commented on 2017-08-07 15:58

I didn't want to bump it for such a minor change especially when the August update is very close.

oconnor663 commented on 2017-08-07 15:26

@dcelasun fixed for me, thanks. We could bump the packaging version?

dcelasun commented on 2017-08-05 09:07

@oconnor663: Thanks for reporting this, I can reproduce this as well. Originally, I've added StartupWMClass=code as someone in the comments was having problems running it on Gnome without it. That no longer seems to be the case, so I'll be removing it.

Edit: Removing it definitely works, but I don't understand why. `xprop WM_CLASS` seems normal:

$ xprop WM_CLASS
WM_CLASS(STRING) = "code", "Code"

oconnor663 commented on 2017-08-04 22:27

I've noticed that when I start VSCode from my Activities menu under gnome-shell, it seems to drop out of the Alt-Tab menu. I can Alt-Tab away, but when I try to Alt-Tab back it's not available anymore. (Though the window is still visible and working, and clicking on it to focus works fine.) This problem goes away if I start the app as `code` in my terminal -- if I do that, Alt-Tab afterwards always works. It also works if I delete the StartupWMClass line from the .desktop file, and then start it the gnome-shell way. In fact, even *editing* that line to use a class name other than "code" seems to fix the problem! Is there something particularly buggy about `StartupWMClass=code`?

dcelasun commented on 2017-08-04 19:10

@vesath: Done.

vesath commented on 2017-08-04 18:47

Please use sha256sums instead of md5sum, since that is the type of checksum that upstream provides.

xaver commented on 2017-07-19 10:21

@Jristz: In addition to what dcelasun just wrote: In fact the visual-studio-code-oss package is wrongly named since the name of the open source product is not "Visual Studio Code" but rather just "vscode". Microsoft do not allow the Visual Studio branding to be used on any other distribution of vscode but their own (cf
Somewhat comparable to the properly named Google Chrome and Chromium (and not google-chrome for Chromium and google-chrome-bin for the actual Google Chrome), it should be visual-studio-code for the EULA'd version and vscode for the MIT licenced OSS version.

dcelasun commented on 2017-07-19 05:36

@Jristz: Please read the comment history of both packages. The names are like that because the software wasn't open source when it was first released, and by the time Microsoft decided to release it as OSS, this package had already a lot of traction (it's in the top 3 most popular packages on AUR) and it wasn't considered worthwhile to break people's updates for purity reasons. For more details, read the comments.

Anonymous comment on 2017-07-19 05:29

This is a binary, right? then it should be named visual-studio-code-bin to follow the common name scheme used on aur, if you aren't sure asl on aur-general.

also the visual-studio-code-oss is using the sources so to also follow the correct name it should be just visual-studio-code.

what a mess those two packages.

xaver commented on 2017-06-20 07:53

This is still an open issue:
You can add the parameters to the startup script /opt/visual-studio-code/bin/code, but this is not a stable solution since you have to do this again for every update.

hendry commented on 2017-06-20 03:30

Thank you xaver!

code --high-dpi-support=true --force-device-scale-factor=1.5 # works great!

But how do I save this preference in a config?