Add anylinux-appimage

[Shikakiben]

Summary

This PR adds an appImage build based on quick-sharun (Anylinux-AppImages tools) as a modern alternative to the legacy pkg2appimage-based AppImage.

It introduces:

• build/linux/anylinux-appimage/get-dependencies.sh — extracts the VSCodium binary, sets up desktop entries, and installs the CLI-routing hook
• build/linux/anylinux-appimage/make-appimage.sh — builds the AppImage with quick-sharun
• build/linux/anylinux-appimage/cli-router.hook — a hook that routes every launch through the codium CLI script, so codium --install-extension ... (and all CLI commands) work from the AppImage
• Integration in publish-stable-linux.yml, publish-insider-linux.yml and ci-build-linux.yml: the build job uploads a vscode-bin-{arch} artifact (x64/arm64), and a new anylinux-appimage job builds the AppImage in a pkgforge-dev/archlinux container and uploads/releases it
• test-anylinux-appimage.yml — a standalone workflow to test the pipeline

Validation

• ✅ The core pipeline (get-dependencies.sh + make-appimage.sh + cli-router.hook) is tested and working via test-anylinux-appimage.yml and ci-build-linux.yml .
• ⚠️ The end-to-end run inside publish-stable-linux.yml could not be completed on my fork: the build job (matrix) fails on unrelated issues — a network timeout hitting archive.ubuntu.com (port 80) in the legacy pkg2appimage step, and a failing build (RISCV64) job. Since anylinux-appimage depends on the build job, it was skipped.
• The binary consumed by anylinux-appimage is produced identically to the working test: same container (vscodium/vscodium-linux-build-agent:focal-x64), same package_bin.sh, same tar command.

HI 👋🙂

i made the Explanations above with AI because my english is not very good 😅 i use Visual-Studio-Code-AppImage as exemple it also provide an arm release and should work on alpine (didn't test it). as said above the anylinux-appimage work but i can not be certain about the integration, also the integration add the anylinux-appimage but don't replace the other appimage not my call to do that.
it should fix #2694 and #2436

[daiyam]

@Shikakiben Can you remove the old appimage? If your version is good, it should replace the old-broken appimage ;)

@Samueru-sama Based on your experience with https://github.com/pkgforge-dev/Visual-Studio-Code-AppImage, does the resulting appimage can access the system env variables like LD_LIBRARY_PATH, PYTHONHOME or PYTHONPATH? Thx

[Samueru-sama]

@Samueru-sama Based on your experience with https://github.com/pkgforge-dev/Visual-Studio-Code-AppImage

I don't use the VIsual-Studio appimage xd

does the resulting appimage can access the system env variables like LD_LIBRARY_PATH, PYTHONHOME or PYTHONPATH? Thx

Yes if you set LD_LIBRARY_PATH=/path/to/random you will be able to see that from the appimage. However the appimage itself will not load any library from there, since it will always load its own libraries first via --library-path in sharun.

Loading libraries from the host will just cause the appimage to crash.

iirc the original appimage from here had a problem that it set LD_LIBRARY_PATH internally and this broke external tools in the host because LD_LIBRARY_PATH leaked to those processes, we have a fix for that in anylinux.so that just checks if LD_LIBRARY_PATH contains $APPDIR in it and intercepts execve calls to external processes to unset the variable to prevent this issue.

In any case we also don't use LD_LIBRARY_PATH at all internally, the bundled binaries are called with the dynamic linker and the --library-path flag, which works like LD_LIBRARY_PATH without the downsides of being an env var that can leak to external processes or we end up overriding the existing LD_LIBRARY_PATH.

[Shikakiben]

@Shikakiben Can you remove the old appimage? If your version is good, it should replace the old-broken appimage ;)

done👍 i kept the legacy appimage folder (but it is link to nothing, you can delete it if you want) , i also modified the release-notes.md to match the change. 🙂

[daiyam]

Sorry, I'm a bit busy which my current task. I will get back to this PR and VSCodium as soon as I've finished it.

[nilltadios]

Coming from #2963 at @daiyam's request. I'm on Debian testing (forky), where FUSE 2 has been removed from the archive, so the current pkg2appimage AppImage doesn't start at all. I built this PR's AppImage locally and tested it there.

Build. Replicated the anylinux-appimage job in ghcr.io/pkgforge-dev/archlinux:latest - pkgforge-dev/anylinux-setup-action v2's setup script, then get-dependencies.sh, then make-appimage.sh, all unmodified from this branch (d412f6f). The one deviation: I fed it VSCodium's released VSCodium-linux-x64-1.126.04524.tar.gz as vscode-bin.tar.gz instead of a fresh compile. The layout is identical to what the build job produces (tar -czf ... -C VSCode-linux-x64 .), so the packaging path is exercised as-is, but the compile step is not.

Result: VSCodium-1.126.04524-anylinux-x86_64.AppImage, 182 MB versus 209 MB for the current 1.126.04524 AppImage, with the .zsync generated and quick-sharun's own smoke test passing.

Test conditions. no libfuse2t64 , ldconfig -p | grep -c libfuse.so.2 → 0, fusermount3 still present and setuid.

Current AppImage (pkg2appimage), for reference:

$ ./VSCodium-1.126.04524.glibc2.34-x86_64.AppImage -- --version
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run.

exit 1 - the failure from #2963.

The AppImage built from this PR, same machine, same conditions:

$ ./VSCodium-1.126.04524-anylinux-x86_64.AppImage --version
1.126.04524
4c0b0c6cc561d2d3636d1ec250935431876ce4dc
x64

exit 0. It mounts as fuse.dwarfs in /proc/mounts, and the binary contains no reference to libfuse.so.2 at all (the current one contains six, plus the "AppImages require FUSE" string).

Two incidental findings. --list-extensions also exits 0, and CLI arguments work directly - the current AppImage requires the -- prefix (appimage -- --version) because of the pkg2appimage AppRun, whereas the cli-router.hook here handles them without it, which looks relevant to #2694.

One more thing I checked on the artifacts: existing AppImages carry the update info gh-releases-zsync|VSCodium|vscodium|latest|*.AppImage.zsync, and the asset this PR produces is named VSCodium-1.126.04524-anylinux-x86_64.AppImage.zsync, which still matches that glob. So users already running the AppImage should migrate to the new build on their next update rather than being stranded on the old one.

On this evidence the PR fixes #2963 outright.

[daiyam]

I will make some changes to the workflows and update value replacements to make it more generic.

[daiyam]

@Shikakiben Make sure to disclose your use of IA when coding. Because leaving a </tool_result> can't be more clear.

Anyways, I've merged your 2 scripts and anonymize it so it can be used for derived IDEs.
I reworked the workflows to support DISABLED and SHOULD_BUILD_APPIMAGE variables.

[daiyam]

@Shikakiben Thanks

[daiyam]

@Samueru-sama and @nilltadios Thank for your feedback

[daiyam]

Hi,

I've tested the AppImage with https://github.com/VSCodium/vscodium-insiders/releases/tag/1.135.05934-insider

Without --no-sandbox, I get the following error with the --verbose flag:

[5425:0907/234612.635632:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] 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 /tmp/.mount_VSCodremp15909897850992891061/bin/chrome-sandbox is owned by root and has mode 4755.

Shouldn't the --no-sandbox flag be on by default?
@Shikakiben @Samueru-sama @nilltadios

[Samueru-sama]

Hi,

I've tested the AppImage with https://github.com/VSCodium/vscodium-insiders/releases/tag/1.135.05934-insider

Without --no-sandbox, I get the following error with the --verbose flag:

[5425:0907/234612.635632:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] 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 /tmp/.mount_VSCodremp15909897850992891061/bin/chrome-sandbox is owned by root and has mode 4755.

Shouldn't the --no-sandbox flag be on by default? @Shikakiben @Samueru-sama @nilltadios

Ubuntu 24 and newer? If you you hit the namespace restriction they put which breaks electron apps.

Running with --no-sandbox is a very bad idea and I do not recomment, instead include fix-namespaces.hook in the ADD_HOOKS variable when deploying, each new entry is separated by :.

https://github.com/pkgforge-dev/Anylinux-AppImages/blob/main/useful-tools/hooks/fix-namespaces.md

[daiyam]

@Samueru-sama Thx

[daiyam]

Ok. It's working fine on the 3 systems I've tested (Ubuntu 25.10, Fedora 38, Debian 13).

The only problem I have is with the icon on Ubuntu. It doesn't use the correct one. But I have the same issue with Galculator
Not a blocker...

[Samueru-sama]

Ok. It's working fine on the 3 systems I've tested (Ubuntu 25.10, Fedora 38, Debian 13).

Common, we test on systems much older than that xd

Ubuntu 14

The only problem I have is with the icon on Ubuntu. It doesn't use the correct one. But I have the same issue with Galculator Not a blocker...

I believe that is normal if you are using GNOME Wayland, since it doesn't support xdg-toplevel-icon

If you meant the appimage icon in the filemanager, that's because you need a thumbnailer that supports dwarfs, basically: https://github.com/kem-a/appimage-thumbnailer