Linux on ARM

[BurningPho3nix]

Greetings,
can the next release include a Linux aarch64/arm64 build so that one can use the app outside of the browser on Linux on ARM machines?

Example: I'm currently testing a rpi cm5l based Laptop

[CompactAIOfficial]

Who says "Greetings" lol
Anyway
Just ask Claude Code or something like that to compile the app for your device

[BurningPho3nix]

Just thought it might be easy to add to the build pipe for releases

[shivamhwp]

try this in the meantime : https://x.com/maria_rcks/status/2030076417992708301

added to internal issues and let the team know.

[BurningPho3nix]

What's the status on this?

Btw, maintaining .rpm packages for this now for more than a month

[BurningPho3nix]

I still need to find the time to build 0.0.33 as a rpm

[oskarsss]

I successfully built the current main branch as a native Linux ARM64 AppImage without making any source changes.

Environment

• Device: Apple MacBook Pro (16-inch, M1 Max, 2021)
• Architecture: aarch64
• OS: Fedora Linux Asahi Remix 44
• Kernel: 7.1.6-400.asahi.fc44.aarch64+16k
• Commit: fd51561b4e2de1893cb7eb4069937256d702572c

Build commands

After installing Vite+ and the repository dependencies, I ran:

vp i
vp run dist:desktop:artifact --platform linux --target AppImage --arch arm64 --verbose

The build completed successfully and produced:

release/T3-Code-0.0.33-arm64.AppImage

The artifact was approximately 153 MiB. file identified it as an ARM AArch64 ELF executable, and I also successfully extracted its SquashFS/AppDir contents. The bundled Electron binary is native AArch64, and ldd reported that all of its shared-library dependencies were resolved.

On Fedora, launching the AppImage itself required these compatibility/runtime packages:

sudo dnf install zlib-ng-compat-devel fuse

Without them, the AppImage runtime reported a missing libz.so and then a missing fusermount. As a FUSE-free alternative, the image can be extracted and launched with:

./T3-Code-0.0.33-arm64.AppImage --appimage-extract
./squashfs-root/AppRun

This confirms that the existing desktop build script already supports Linux ARM64. The remaining work appears to be adding an ARM64 Linux entry alongside the existing x64 entry in the release workflow, using the maintainers' preferred ARM64 CI runner. It should add ARM64 rather than replace x64.

I found the earlier PR #1755, but it was closed unmerged by its author shortly after opening and replaced the x64 build rather than adding a second architecture. I could not find a currently open PR that adds a Linux ARM64 AppImage release job.

Would you accept a small PR that adds Linux ARM64 to the release matrix? If so, which ARM64 runner label should be used with the current Blacksmith setup?

I can also test an official CI-produced artifact on this ARM64 Fedora/Asahi machine once one is available.

[BurningPho3nix]

Does it execute correctly under aarch64 as an AppImage?

[birkskyum]

I ran into this while trying to install T3 Code through Omarchy on an ARM64 PC. Omarchy includes T3 Code in its installer, but the AUR package only provides the x86-64 AppImage. On aarch64, the installation fails with an architecture error and then an Exec format error.

The browser-based npm version is a possible workaround, but it isn’t a replacement for the packaged desktop app or a smooth native installation.

Since the desktop app has already been built successfully for Linux ARM64, could an ARM64 AppImage be added to the official releases? That would also allow the AUR package and Omarchy installer to support ARM PCs properly.

[BurningPho3nix]

You can look at how I build the rpm and replicate that

[birkskyum]

Thanks, its great to know the RPM build already works. What would make the biggest difference for Omarchy and AUR is having that ARM64 build included in the official releases. Then downstream installers could use a stable upstream artifact instead of rebuilding it themselves.