Describe the bug
The Linux AppImage fails to start on distributions that no longer ship FUSE 2:
dlopen(): error loading libfuse.so.2
AppImages require FUSE to run.
Debian testing (forky) has removed FUSE 2 from the archive - both libfuse2 and libfuse2t64 report Candidate: (none) there, only fuse3 is available. The usual "install libfuse2" advice therefore no longer works on it.
Scope: of the 113 repositories Repology tracks packaging libfuse, 13 carry only 3.x. Excluding non-distro entries (vcpkg, spack, wikidata) and overlay repos that inherit from a base (KDE neon layers on Ubuntu), the affected distributions are at least Debian
testing, Kali rolling, Chimera Linux, GoboLinux and PLD. Kali is confirmed independently: pkg.kali.org lists only src:fuse3 (3.18.2-2) across kali-roll/kali-dev, with no src:fuse.
Most distros are still fine - Ubuntu through 26.10, Fedora, Arch, Alpine, openSUSE, Gentoo, Nix, Void and Mageia all still ship libfuse 2.9.9, as do Debian stable and unstable. But this is not a transient glitch: there is an open removal request for src:fuse (Debian bug #1123774, filed 2025-12-21), and the package tracker notes that once processed it "will no longer be in unstable, and will automatically be removed from testing too". Kali already demonstrates how that propagates to Debian derivatives, so the set of affected distributions grows rather than shrinks.
Cause: build/linux/appimage/build.sh builds through pkg2appimage → generate_type2_appimage, whose legacy type-2 runtime dlopens libfuse.so.2. Visible in the shipped asset:
$ head -c 3000000 VSCodium-1.126.04524.glibc2.34-x86_64.AppImage | strings \
| grep -E 'libfuse\.so\.2|squashfuse'
libfuse.so.2
squashfuse
Please confirm that this problem is VSCodium-specific
To be precise: Microsoft publishes no AppImage at all, so there is nothing to compare against. This is specific to the VSCodium AppImage artifact rather than to VSCodium's code.
Please confirm that the issue/resolution isn't already documented
To Reproduce
- Use a distro without FUSE 2 available (e.g. Debian testing/forky)
- Download
VSCodium-1.126.04524.glibc2.34-x86_64.AppImage and chmod +x it
- Run it
- See the
dlopen() error above
Expected behavior
The AppImage starts without requiring a library that is EOL upstream and no longer packaged by some distributions.
Desktop
- OS: Debian GNU/Linux forky/sid (testing)
- Architecture: x64
- Version: 1.126.04524
- App Manager: AppImage (via Gear Lever)
- Sandboxed: no
Additional context
Local workaround: install libfuse2t64 2.9.9-9+b2 from Debian unstable (Depends: libc6 only). Debian's /usr/bin/fusermount → setuid fusermount3 symlink satisfies FUSE 2's helper requirement, and the AppImage then mounts natively. This isn't something most users will find on their own, and it pins them to an EOL library.
Modern AppImage runtimes avoid the dependency entirely - they use FUSE when present, fall back to namespaces, and finally to extract-and-run. #2950 would add such a build via quick-sharun, but as written it adds a variant rather than replacing the pkg2appimage build, so the default published asset would still require libfuse2.
Describe the bug
The Linux AppImage fails to start on distributions that no longer ship FUSE 2:
Debian testing (forky) has removed FUSE 2 from the archive - both
libfuse2andlibfuse2t64reportCandidate: (none)there, only fuse3 is available. The usual "install libfuse2" advice therefore no longer works on it.Scope: of the 113 repositories Repology tracks packaging libfuse, 13 carry only 3.x. Excluding non-distro entries (vcpkg, spack, wikidata) and overlay repos that inherit from a base (KDE neon layers on Ubuntu), the affected distributions are at least Debian
testing, Kali rolling, Chimera Linux, GoboLinux and PLD. Kali is confirmed independently: pkg.kali.org lists only
src:fuse3(3.18.2-2) across kali-roll/kali-dev, with nosrc:fuse.Most distros are still fine - Ubuntu through 26.10, Fedora, Arch, Alpine, openSUSE, Gentoo, Nix, Void and Mageia all still ship libfuse 2.9.9, as do Debian stable and unstable. But this is not a transient glitch: there is an open removal request for src:fuse (Debian bug #1123774, filed 2025-12-21), and the package tracker notes that once processed it "will no longer be in unstable, and will automatically be removed from testing too". Kali already demonstrates how that propagates to Debian derivatives, so the set of affected distributions grows rather than shrinks.
Cause:
build/linux/appimage/build.shbuilds throughpkg2appimage→generate_type2_appimage, whose legacy type-2 runtimedlopenslibfuse.so.2. Visible in the shipped asset:Please confirm that this problem is VSCodium-specific
To be precise: Microsoft publishes no AppImage at all, so there is nothing to compare against. This is specific to the VSCodium AppImage artifact rather than to VSCodium's code.
Please confirm that the issue/resolution isn't already documented
To Reproduce
VSCodium-1.126.04524.glibc2.34-x86_64.AppImageandchmod +xitdlopen()error aboveExpected behavior
The AppImage starts without requiring a library that is EOL upstream and no longer packaged by some distributions.
Desktop
Additional context
Local workaround: install
libfuse2t642.9.9-9+b2 from Debian unstable (Depends: libc6only). Debian's/usr/bin/fusermount→ setuidfusermount3symlink satisfies FUSE 2's helper requirement, and the AppImage then mounts natively. This isn't something most users will find on their own, and it pins them to an EOL library.Modern AppImage runtimes avoid the dependency entirely - they use FUSE when present, fall back to namespaces, and finally to extract-and-run. #2950 would add such a build via quick-sharun, but as written it adds a variant rather than replacing the pkg2appimage build, so the default published asset would still require libfuse2.