It doesn't start anymore without manually adding --no-sandbox to ~/.config/code-flags.conf now.
Why was this removed from the .desktop files?
| Git Clone URL: | https://aur.archlinux.org/visual-studio-code-bin.git (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: | https://code.visualstudio.com/ |
| Licenses: | custom: commercial |
| Conflicts: | code |
| Provides: | code, vscode |
| Submitter: | dcelasun |
| Maintainer: | dcelasun |
| Last Packager: | dcelasun |
| Votes: | 1698 |
| Popularity: | 28.88 |
| First Submitted: | 2017-12-18 19:14 (UTC) |
| Last Updated: | 2026-07-22 18:51 (UTC) |
« First ‹ Previous 1 .. 27 28 29 30 31 32 33 34 35 36 37 .. 94 Next › Last »
It doesn't start anymore without manually adding --no-sandbox to ~/.config/code-flags.conf now.
Why was this removed from the .desktop files?
Added icu69 to optdepends.
Yes,as below, live share does not work unless icu69 package is installed. Please add it (or icu69-bin which I used?) to the dependencies.See this issue.
After a recent upgrade, liveshare stopped working
command 'liveshare.startFromWelcomeContent' not found: Error: command 'liveshare.startFromWelcomeContent' not found
After consulting https://docs.microsoft.com/en-us/visualstudio/liveshare/reference/linux, I ran the script for the required dependencies, which indicated that icu69 was missing.
After installing the icu69 AUR package (https://aur.archlinux.org/packages/icu69), live share now works.
I've installed another arch in VM to specifically test this aur package with the sign in to sync settings issue I'm facing, and it is my machine, not the package, that is at fault. I don't know what to do to solve it but it's working fine in VM when I sync settings. I've tried installing on my main machine with and without an aur helper, so some setting somewhere must be being preserved between installs. Sorry to have bothered you.
Edit: paru -Sc did the trick, can now access my codespaces from visual studio code again! \n Edit2: The only thing that confuses me is I did try installing the tarball and doing makepkg -si and as far as I know my solution shouldn't of impacted that, but that still was having the same issue. Maybe it does interact some way?
@phillipk: That should be fixed now, thanks!
@vegancookies: I can't reproduce with Firefox. Could it be related to your browser somehow? I just pushed an update with a minor change to the URL handler, can you update and try again?
Recently I've been unable to sign in via github. It loads the browser for login, takes me through the 2fa process, and then the url handler goes back to vscode, where it attempts to login, but just ends up giving a notification of 'cancelled'.
I've put ubuntu on a virtual machine and the program works perfectly there. I've tried uninstalling and reinstalling, and deleting github authentication files left over from when I was signed in. I've also tried to revoke vscode on github and retry from the start, but the issue persists (only the aur version).
Is there anything the user can do to re-enable this functionality or any additional information you would fine useful (everything on my system is upto date, running arch vanilla).
The wrapper script in /usr/bin/code seems broken for me in some way. Running it in the terminal as code . does not seem to pass the current directory (either the last workspace or a blank instance opens).
/opt/visual-studio-code/code . works, however.
Sadly, I am too bad at bash to see the problem.
EDIT: Nvm, I have found a solution: If the path is passed as the first argument to /opt/visual-studio-code/bin/code it is working. So line 11 of the wrapper should be exec /opt/visual-studio-code/bin/code "$@" $CODE_USER_FLAGS
I suspect it has to do with line breaks in $XDG_CONFIG_HOME/code-flags.conf?
Are you able to add KDE wallet integration to this package?
I had to add ''gnome-keyring'' to be able to sync with my other copies of vs code, and it won't stop asking me for my default keyring.
The Wayland issue seems to be an Electron problem [1] and should be fixed by Electron v17.3.1, which was released 2 days ago [2]. They might (or might not) include this in the upcoming recovery build [3]. In the meantime, there are workarounds mentioned in the bug report [1].
[1] https://github.com/microsoft/vscode/issues/146349
[2] https://github.com/electron/electron/releases/tag/v17.3.1
Pinned Comments
dcelasun commented on 2017-11-15 06:20 (UTC) (edited on 2026-06-04 12:33 (UTC) by dcelasun)
FREQUENTLY ASKED QUESTIONS (read before flagging or commenting!)
This is the official binary distribution from Microsoft. The one in the community repo is an unofficial build made from source. Beyond the licence difference and branding, there are some proprietary features not available in the open-source version.
This package depends on the official tarball. Please check this page before flagging as out-of-date. If the new version isn't on that page, this package cannot be updated! If you can see the new version there, but the AUR package is still not updated, flag it and give it time. It's usually done within hours.
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.xdg-openuses vscode, not my file manager! How do I fix this?Install
shared-mime-info-gnomegnome-sessionwhich now includes mimemapps.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.
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.
No, you won't get a reply. Please stop doing this. Leave a comment here instead and be patient.