Overriding XDG_DATA_HOME in snap leads to multiple problems

[LoicGrobol]

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

Version: 1.97.0-insider Commit: 9b0b13d9bfe21c3dfd227bfaa8ed5693e309a2e0 Date: 2025-01-08T05:06:32.681Z Electron: 32.2.7 ElectronBuildId: 10660205 Chromium: 128.0.6613.186 Node.js: 20.18.1 V8: 12.8.374.38-electron.0 OS: Linux x64 6.12.8-1-MANJARO snap

2d28c0a79c87 added a feature that redefines XDG_DATA_HOME to be $SNAP_USER_DATA/.local/share. This leads to several problems

• This creates a bogus Trash that's not the system one, and as such is unmanageable (and is carried over from update to update, gradually inflating) : #233649, #237147
• Since it also applies to commands run in the integrated terminal, all programs that use XDG dirs will only see the local snap ones instead of the system ones. E.g. :
  • Messing up fish (#232741) and Xonsh histories
  • Creates a separate brittle data dir for uv (what lead me here)
  • Creates a separate root for virtualenvwrapper, with environments created outside vscode not accessible inside and vice-versa
  • Probably many other subtle and hard to track bugs

Would it be possible to revert this, or at least have an option to make it opt-out-able?

[LoicGrobol]

ping @deepak1556 i guess

[LoicGrobol]

A temporary fix for the terminal issues is to set "terminal.integrated.env.linux": {"XDG_DATA_HOME": "/home/<username>/.local/share"} in settings.

[iainlane]

Some other problems that I noticed were caused by this change

• Locally installed fonts - in ${XDG_DATA_HOME}/fonts - stopped being found
• neovim reconfigured itself
• systemd tools don't see local units etc
• podman downloads all containers again

the list goes on... Basically yes, please can you revert this part of the change? 🙏

The terminal workaround works for some of these, but not the fonts thing. For that one specifically, you can run as XDG_DATA_DIRS=${XDG_DATA_HOME}:${XDG_DATA_DIRS} code to stuff your home directory into the system one used by the snap.

[RafaelWO]

I have similar problems after I have switched from the .deb installation to snap (Ubuntu 24.04.1 LTS)

• Fonts not found (fixed by this workaround)
• Fish history is different (see also https://github.com/microsoft/vscode/issues/232741)
  • My main terminal writes it to .local/share/fish/fish_history
  • VSCode writes it to /home/rafael/snap/code/179/.local/share/fish/fish_history
• uv python installations are stored in different places
  • Non-VSCode terminal:
  • VSCode terminal:

---

A temporary fix for the terminal issues is to set "terminal.integrated.env.linux": {"XDG_DATA_HOME": "/home/<username>/.local/share"} in settings.

The workaround from above works for me, thanks @LoicGrobol!

[p-himik]

Another example: executing podman run would result in the "container already exists" error even though any attempts to find that container would fail. Turns out, XDG_DATA_HOME was to blame and the suggested settings change fixes it.

Weirdly enough though, the env var was mentioning snap/code/180 initialy but according to strace, podman was actually using snap/code/176 for some reason. No clue why.

[jeckst]

I've been having issues with Jupyter notebooks in vscode (see here and here) with kernel definitions (which by default live in /home/<username>/.local/share/jupyter/… not being found, moving around and not being detected.

One of the symtoms I've seen was that jupyter kernelspec list gives different output based on whether I run it in the integrated terminal or in a standalone system terminal (see here).

Could someone here help me confirm that these are connected to this issue — could anyone recommend any way to check? Or should I create a separate issue for that?

[p-himik]

could anyone recommend any way to check?

You could try the suggested workaround and see if that fixes the issue on your side.

[jeckst]

@p-himik Yeah, I've done that and it does fix the output discrepancy within the terminals, but I don't expect it to fix the core problem of losing kernels in the notebooks, since that is not necessarily run by the terminal, I guess. And since that is an intermittent problem, it's not easy to dependably test anyway, so I am looking for some way to diagnose that this is the root cause of those issues.

[LoicGrobol]

@jeckst It seems like it could be related at least! What led me to originally investigate this was uv virtual environments (which as this point some were in the snap tree and others in the regular home) jumping around. As in the list of available environments would change under my eyes while I was trying to select one. And it does look like jupyter uses the xdg path env variables (through platformdirs) in kernelspec. I guess you could set JUPYTER_*_DIR to their locations in your home when invoking vscode? I don't think it would overwrite them.

[jeckst]

@LoicGrobol Thanks for the pointers, I will try that

[cas--]

I encountered this with missing Atuin shell history in VSCode snap with a suggestion to create a link for Atuin, the same as Monospace fonts not working, however that seemed like a band aid and now can see it a much bigger issue.

Thanks @LoicGrobol for terminal workaround, a slight tweak to use $HOME env var would match usual env var setting:

  "terminal.integrated.env.linux": {
    "XDG_DATA_HOME": "${env:HOME}/.local/share"
  }

@deepak1556 Is preserve sys vars feature, implemented in https://github.com/microsoft/vscode/pull/185834, working as expected? My reading of the change suggested that under snap vscode the terminals would revert to original env vars but I don't see that happening:

$ echo $XDG_DATA_HOME
~/snap/code/182/.local/share
$ echo $XDG_DATA_HOME_VSCODE_SNAP_ORIG
<empty>
$ echo $XDG_DATA_DIRS
~/snap/code/182/.local/share/flatpak/exports/share:~/snap/code/182/.local/share:~/snap/code/182:/snap/code/182/usr/share:/usr/share/ubuntu:/usr/share/gnome:~/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop:~/.nix-profile/share:/nix/var/nix/profiles/default/share:~/.nix-profile/share:/nix/var/nix/profiles/default/share:~/.nix-profile/share:/nix/var/nix/profiles/default/share
$ echo $XDG_DATA_DIRS_VSCODE_SNAP_ORIG 
/usr/share/ubuntu:/usr/share/gnome:~/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop:~/.nix-profile/share:/nix/var/nix/profiles/default/share

[konstin]

uv is affected by too, with a user reporting they spent on hours debugging this: https://github.com/astral-sh/uv/issues/14849

CC @karthiknadig as this affects the VS Code Python experience.

[Meekohi]

e.g. this bug causes podman run on the vscode terminal to successfully start pods (sometimes?) but they will not show up if you podman ps even though they are in fact still running on your system. (took quite some time to track down that this was the issue)

P.S. The work-around did work for me.