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

Git Clone URL: (read-only, click to copy)
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
Provides: code
Submitter: dcelasun
Maintainer: dcelasun
Last Packager: dcelasun
Votes: 995
Popularity: 19.11
First Submitted: 2017-12-18 19:14
Last Updated: 2021-03-05 06:57

Required by (11)

Sources (6)

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), 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.

Latest Comments

1 2 Next › Last »

ak04nv commented on 2021-03-05 04:15


This package allows using the new python language server pylance. An unofficial build from the community repo it doesn't.

dcelasun commented on 2021-03-04 20:30

@tomatopeel clone the git repo (, switch to an older commit, run updpkgsums (from the pacman-contrib package) and install with makepkg -si.

@Nehu I've removed the conflict with code. Let me know if there are any issues.

codewing commented on 2021-02-23 09:21

I have the same issue as DonJogi here. (for ctrl+f people like me: InitializeSandbox())

There seems to be something broken between keepassxc and vscode. I used the secret service integration but if I have it and keepassxc running then vscode crashes on startup. I fixed this by removing the vscode sync entry in keepassxc and then it worked again even after syncing it again. Weird...

kaiserbh commented on 2021-02-17 22:32

thanks the one one in the community repo has a signing issue, it just stuck on loading for me, but this version seem to have fixed that and managed to sync my settings.

tomatopeel commented on 2021-02-17 16:41

I want to install an older version because the new version is performing worse for me, so I need to test if that is the problem.

When I try to install any older major version, I get e.g.:

==> Validating source_x86_64 files with sha256sums...
    code_x64_1.52.0.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!

How can I install an older version? Cheers

Nehu commented on 2021-02-13 19:28

Would it be possible to not mark this package as not conflicting with code?

As far as I'm aware, the OSS version and this one do not share the same config folder (~/.config/Code vs ~/.config/Code OSS).

Removing the "conflicts" statement would allow a parallel installation of both, which in turn is useful for using this binary release for C# development (in a properly secured environment) and the OSS release (in a more flexible environment) for everything else.

neo2001 commented on 2021-02-12 11:42

No crashes here either.

dcelasun commented on 2021-02-12 11:27

@cusidawgs it's not crashing for me. Perhaps you should report it upstream?

cusidawgs commented on 2021-02-12 11:25

Is it just me or the new version crashes on my installation. Followed all steps on the pinned comment and deleted every vscode configuration folder, yet the problem still persists

mcmar commented on 2021-02-11 22:54

Thank you @bulletmark. I'm not using yay, but the package cache was the issue.

dcelasun commented on 2021-02-11 21:01

Also refer to the stickied FAQ please, particularly the third bullet point.

bulletmark commented on 2021-02-11 21:00

@mcmar, delete the cached file, e.g rm -rf ~/.cache/yay/visual-studio-code-bin then run yay again.

dcelasun commented on 2021-02-11 20:58

@mcmar I've pushed a new release with updated checksums. Did you try installing 1.53.1-2?

mcmar commented on 2021-02-11 20:54

@dcelasun I don't understand. You said it "should be fine now" and then said "read the comment below". I read all the comments and it's not fine. The package update still fails. What's the fix?

emptyDir commented on 2021-02-11 20:23

@dcelasun thanks!

dcelasun commented on 2021-02-11 19:44

@GeneralPoxter read the comment below.

GeneralPoxter commented on 2021-02-11 19:43

I got the following error:

==> Validating source_x86_64 files with sha256sums...
    code_x64_1.53.1.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!
error downloading sources: visual-studio-code-bin

dcelasun commented on 2021-02-11 19:31

@emptyDir looks like they've replaced the x64 package without releasing a new version. Should be fine now.

emptyDir commented on 2021-02-11 19:28

Looks like the PKGBUILD has an incorrect checksum for the x86_64 package:

 ==> Validating source_x86_64 files with sha256sums...
    code_x64_1.53.1.tar.gz ... FAILED



Downloaded the package manually and compared the checksum to the version downloaded by makepkg, and they seem consistent, but don't match the above:

$ sha256sum code_x64_1.53.1.tar.gz 
23c93a7bf6ceed346f9f2034b4630d8d497dcc3f4b9cce6b67f08f8d272e1530  code_x64_1.53.1.tar.gz
$ sha256sum ~/Downloads/code-stable-x64-1613044905.tar.gz 
23c93a7bf6ceed346f9f2034b4630d8d497dcc3f4b9cce6b67f08f8d272e1530  /home/emptyDir/Downloads/code-stable-x64-1613044905.tar.gz

PrfStrwberry commented on 2021-01-06 20:00

EDIT: I think it was caused by firejail. I enabled firejail for every program with #firecfg. Cleaning with #firecfg --clean and vs code started after right click -> open with.

Although one or two months ago, the problem did not exist.

When visual-studio-code-bin is closed, are you guys able to open a file by right clicking it and selecting open with vs code?

Nothing happens, when I do that. Kate opens fine.

If I have vs code open, I can right click and select open with vs code and everything works, as supposed to.

EDIT: more specific, text files are fine, json for example not.

bulletmark commented on 2020-12-17 20:52

@dcelasun, note you don't have to bump the pkgrel. Just push the commit. Anybody who already has it installed isn't affected because the built package is the same version anyhow.

dcelasun commented on 2020-12-17 18:57

@Magissia sure, but I don't want to bump pkgrel just for that, so I'll add it with the next release.

Magissia commented on 2020-12-17 18:53

Could you consider adding a "pentium4" architecture to the pkgbuild ? This architecture would still use ia32 archive for installation.

arch variable would need to be modified to arch=('x86_64' 'i686' 'pentium4' 'aarch64' 'armv7h')

Additional source need to be added :


Additional instruction for package() is required : if [ "${CARCH}" = "pentium4" ]; then _pkg=VSCode-linux-ia32 fi

If for any reason Microsoft stop providing the ia32 archive, both i686/pentium4 should be removed.


Thank you.

stronglodge commented on 2020-12-17 00:55

The SHA is wrong for x64, should be 8c30fddfab0b403b68b8151e79a3c2ccb4a3d44ba8e063c0f957f901165e72cd

Det commented on 2020-12-16 15:17


dcelasun commented on 2020-12-15 14:11

@enkeyz AUR packages assume you already have the base-devel group installed. Run pacman -S base-devel and try again.

enkeyz commented on 2020-12-15 13:19

yay giving me error when trying to install: "ERROR: Cannot find the strip binary required for object file stripping."

shastry commented on 2020-11-12 04:33

Please add to PKGBUILD: options=('!strip')

This will speed up packaging significantly.

It is a handy option when repackaging binary.

dcelasun commented on 2020-11-09 19:27

Thanks @ItachiSan and @TheCycoONE, I've updated the PKGBUILD.

ItachiSan commented on 2020-11-09 12:22

Hi @cdelasun,

As @TheCycoONE has mentioned, there are some issues with the sources definition. Sources in the source array (not the _ARCH ones) are used for all architectures, while architecture specific ones will be used on the specific architecture.

With this said you can improve the PKGBUILD in this way:

diff --git a/PKGBUILD b/PKGBUILD
index 1e1ee8d..9801312 100644
@@ -14,38 +14,18 @@ conflicts=('code')
 depends=(libxkbfile gnupg gtk3 libsecret nss gcc-libs libnotify libxss glibc lsof)
 optdepends=('glib2: Needed for move to trash functionality'
             'libdbusmenu-glib: Needed for KDE global menu')
-               ${_pkgname}.desktop ${_pkgname}-url-handler.desktop)
-               ${_pkgname}.desktop ${_pkgname}-url-handler.desktop
-               )
-               ${_pkgname}.desktop ${_pkgname}-url-handler.desktop
-               )
-               ${_pkgname}.desktop ${_pkgname}-url-handler.desktop
-               )
-              ${_pkgname}.desktop ${_pkgname}-url-handler.desktop
-              )
-            '0deefcb638e06c35a52e7e9fb8e19b2dc393f01e5c1c122d2938cddeb22cf8de'
+source=(${_pkgname}.desktop ${_pkgname}-url-handler.desktop)
+# This generates cleaner checksums
-                   '0deefcb638e06c35a52e7e9fb8e19b2dc393f01e5c1c122d2938cddeb22cf8de'
-                   'be3d123aacd575d8f836728266eb421ea70399d713d1fc30378dbc5602b519fb')
-                 '0deefcb638e06c35a52e7e9fb8e19b2dc393f01e5c1c122d2938cddeb22cf8de'
-                 'be3d123aacd575d8f836728266eb421ea70399d713d1fc30378dbc5602b519fb')
-                    '0deefcb638e06c35a52e7e9fb8e19b2dc393f01e5c1c122d2938cddeb22cf8de'
-                    'be3d123aacd575d8f836728266eb421ea70399d713d1fc30378dbc5602b519fb')
-                   '0deefcb638e06c35a52e7e9fb8e19b2dc393f01e5c1c122d2938cddeb22cf8de'
-                   'be3d123aacd575d8f836728266eb421ea70399d713d1fc30378dbc5602b519fb')

 package() {

TheCycoONE commented on 2020-11-08 12:58

The multiarch handling seems slightly off, on aarch64 it downloads and extracts both the x64 and arm64 versions, and the shared files are checked multiple times.

The end result works, but I think only the non-arch files (.desktop files) belong in source=, and they shouldn't be repeated in the source_arch sections.

dcelasun commented on 2020-10-14 22:58

With version 1.50.1 I've added ARM builds to this package. I don't have an ARM system to test with so let me know if you see any issues.

pfeerick commented on 2020-10-10 11:12

The current version of this package only supports x64, not the (new) arm or arm64/aarch64 builds of VSCode. I had no issues using the official tar.gz for 1.50 from on a Pinebook Pro (aarch64).

spqa commented on 2020-10-09 04:22

To anyone get this error:

:: (1/1) Parsing SRCINFO: visual-studio-code-bin
==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced.
error downloading sources: visual-studio-code-bin

Use command git config --global core.autocrlf false and delete ~/.cache/yay/visual-studio-code-bin might help

Det commented on 2020-10-04 10:00

Pretty common for people to hardcode for Ubuntu.

dcelasun commented on 2020-10-04 09:55

@alosarjos I'd say that's a bug with their tool. Instead of checking a hardcoded path they should look for the code binary in $PATH. I'd report it upstream.

alosarjos commented on 2020-10-04 09:46

I was checking the official binary install paths. Seems to be different than this package. The official Ubuntu .deb seems to install on /usr/share/code.

In the case of the Flutter framework, their doctor tool to check if VSCode is correctly installed has the /usr/share/code/bin/code path hardcoded to check if it's installed on the system, so it doesn't detect the installation from this package.

While this is a minor thing that won't stop Flutter from working with Flutter, I don't know if this could lead to another frameworks or tools problems that need to detect if VSCode is installed using the expected binary path from the official packages.

PD: Thanks a lot for maintaining this package.

J.Kakaofanatiker commented on 2020-10-03 14:20

I get the following error when I try to download it using yay: curl: (7) Failed to connect to port 443: Verbindungsaufbau abgelehnt (Translation: Connection refused)

malkovich commented on 2020-09-04 13:41

Your post has been so helpful because it was clear and concise writing made it easy to understand. Thank you!

dcelasun commented on 2020-08-26 06:00

@samueldy I think you have a corrupted package. I don't see any CRLF characters:

$ grep -U $'\015' visual-studio-code-bin/PKGBUILD

samueldy commented on 2020-08-26 05:21

Updating via yay -Syu gives the error:

:: (1/1) Parsing SRCINFO: visual-studio-code-bin
==> ERROR: PKGBUILD contains CRLF characters and cannot be sourced.
error downloading sources: visual-studio-code-bin

Navigating to the downloaded package directory (~/.cache/yay/visual-studio-code-bin for me), running dos2unix on PKGBUILD and the two .desktop files, and running makepkg -i worked for me.

m4chei commented on 2020-07-15 11:30

I've tried updating from -> using yay today. Updating failes:

curl: (6) Could not resolve host:
==> ERROR: Failure while downloading
Error downloading sources: visual-studio-code-bin

Same thing happens if I run makepkg -si on the tarball.

bhrgunatha commented on 2020-06-02 05:33

I've tried to update this package (pkgver 1.41.1) several times over several days in the last week or so and every time the download times out. I can't even download directly.

HTTP request sent, awaiting response... 404 Not Found

Anyone have similar issues?
Is there an alternative URL?
Any ideas whatsoever welcome.

lordflaron commented on 2020-05-26 03:41

@emke Thanks, can confirm that it failed on pamac, but works with yay

emke commented on 2020-05-20 20:27

@lordflaron after the latest pamac update, I no longer get that error.

dcelasun commented on 2020-05-14 07:25

@lordflaron then that's a problem with pamac. Please read the pinned Frequently Asked Questions.

lordflaron commented on 2020-05-14 07:07

@dcelasun I'm using the pamac GUI with air support

dcelasun commented on 2020-05-14 06:24

@lordflaron that file is definitely in the package. How are you installing this package, with an AUR helper?

lordflaron commented on 2020-05-13 20:53

Hi, I'm getting this error when building:

ERROR: visual-studio-code.desktop was not found in the build directory and is not a URL.

Det commented on 2020-05-08 00:37

shrug yea, maintainers rarely wanna co-maintain (even me back when I was doing it).

mixedCase commented on 2020-05-08 00:35

@Det Yep, I can do the actual download and replace with the actual checksum just as easily, but doing an extra git commit and push would allow me to share it, just wanted to check if that was an option.

Det commented on 2020-05-07 23:09

@mixedCase, well.. on quick glance looks like you could maintain this locally with:

pkgver=$(curl -sL | grep -Pom1 "version \K[^)]*") # cut up from after "version " to the first ")" ("<h1>April 2020 (version 1.45)</h1>"), -m1: use only first result
pkgrel=1 # reset

Put it at the end of the PKGBUILD, and it's a portable piece of text that doesn't even conflict with anything.

mixedCase commented on 2020-05-07 22:50

@dcelasun Yes, and thank you for keeping it within reasonable bounds all this time!. I'm offering because I update packages within the hour (usually less), since I automate new release checks to fire an e-mail usually before an user files the package as out of date, edit the PKGBUILD, make some quick tests and ship it.

As for my personal reason, I've been working with VS Code much more often recently and the damned gear with the notification gets on my nerves, but I understand being hesitant.

Let me know if you do change your mind :)

dcelasun commented on 2020-05-07 21:51

@mixedCase thanks for the offer! Over the years I've managed to keep this updated within hours of release. I'll ping you if that becomes untenable in the future.

mixedCase commented on 2020-05-07 20:54

Hi @dcelasun. I've been using your package for, well a couple of years now. I've noticed that MS tends to release updates during my office hours, making it practical for me to help out making version bumps shortly after releases occur. Would you accept a co-maintainer?

dcelasun commented on 2020-03-31 22:09


Nowaker commented on 2020-03-31 22:07

Would you mind creating visual-studio-code-insiders-bin? The Insiders version of the package would be very similar to this one - only pointing to a different URL, and having sha256sums=SKIP since Insiders is a daily build. Thank you.

dcelasun commented on 2020-03-30 09:36

@op3 done, let me know if it doesn't work as expected.

op3 commented on 2020-03-29 11:02

The upstream code package is providing a .desktop file that includes a “New Empty Window” option. I find this very useful and would appreciate if you introduced this feature to the .desktop file provided with this package.

dcelasun commented on 2020-03-25 19:17

@Xaekai I'm not sure how up-to-date this page is, but Micrososft maintains such a list here.

Xaekai commented on 2020-03-25 19:14

I request that "proprietary features" in your FAQ be linkified to an enumeration of those features if possible. Thank you.

Det commented on 2020-03-24 20:50

Wow, ok, cool. Does that warrant like a FAQ mention?

dcelasun commented on 2020-03-24 20:39

@Det this package is the official build from Microsoft and can use the name "Visual Studio Code". The package in community is an unofficial build and isn't allowed to use Microsoft branding so it's only called "code".

Det commented on 2020-03-24 20:36

So wait, what was the reason again this had a different name from community/code?

Anonymous comment on 2020-02-10 13:50

@dcelasun @jaysistar

I was the maintainer of vscodium-bin-multiarch. I have now added ARM support into vscodium-bin and deleted my package.

From now, vscodium-bin supports ARM and ARM64.

jaysistar commented on 2020-01-31 02:05

@dcelasun Thanks! I'd like Microsoft to support ARM64, but I'll use Codium until they do.

dcelasun commented on 2020-01-30 16:06

@jaysistar this package is only for the official binaries from Microsoft, which doesn't support ARM. Until it does, you can try vscodium-bin-multiarch.

jaysistar commented on 2020-01-30 13:30

Please update this package to work with aarch64.

bulletmark commented on 2019-12-20 00:43

@fifthecho, please don't do that. That's what the flag button is for.

fifthecho commented on 2019-12-20 00:33

1.14.1 is out which has a SHA256 SUM for me of:

2a2353ea85b5a3d729e0134ff36b29461bb4264b708786e2486927b7f3c06601  code-stable-1576682093.tar.gz

panjiesw commented on 2019-11-15 15:05

@dcelasun I also experienced the issue mentioned by @bike-bill In my case my VSCode can't be launched from rofi launcher, which launch /opt/visual-studio-code/code. Running it from CLI got the same error.

But, it's working and opened without error if I launch /opt/visual-studio-code/bin/code

bike-bill commented on 2019-11-14 10:03

@dcelasun I think I somehow deleted my original message that you responded to. My issue is this: I first noticed my Dash icon was not launching Code. When I start from the command line from /opt/visual-studio-code I get:

$ ./code [18860:1114/] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /opt/visual-studio-code/chrome-sandbox is owned by root and has mode 4755. Trace/breakpoint trap (core dumped)


sudo chmod 4755 /opt/visual-studio-code/chrome-sandbox

fixes the issue.

dcelasun commented on 2019-11-13 14:49

@bike-bill This package doesn't set the SUID bit (so 0755) but I don't see any errors.

$ ls -alh /opt/visual-studio-code/ | grep sandbox
-rwxr-xr-x 1 root root 231K Nov  8 10:07 chrome-sandbox

LiteracyFanatic commented on 2019-10-30 08:43

I'm not sure if this is an upstream issue or a packaging one, but none of the hover tooltips work for me with this package. They do work with the open source package in community. Anybody else having this issue?

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.

Anonymous comment 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.

nobody11 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?