2 October 2026 · PR #7765

T3 Code running in an ARM64 VM

The static ARM64 AppImage mounted without system libfuse2, started its backend, rendered T3's onboarding and home screen, and responded to onboarding controls. After a full guest reboot, a fresh process reached backend readiness and rendered the full home screen with the saved state, without another Reload.

Actual guest screenshots

T3 Code home screen running in the ARM64 VM, with guest architecture and FUSE evidence in a terminal below — Full T3 home screen after completing onboarding. The terminal shows actual guest command output, including aarch64, the static runtime's FUSE mount, and the legacy control's missing-libfuse2 failure.

T3 Code home screen after rebooting the ARM64 guest and launching the same AppImage — Fresh launch after reboot. The new FUSE mount and startup timestamps appear in the guest terminal. No Reload was needed on this launch.

Onboarding screenshot showing t3-arm64-vm connected · Download screenshots, logs, build configurations, and hashes

What was tested

Debian 13.7 ARM64, kernel 6.12.111+deb13-arm64, fuse3 3.17.2-3, no libfuse2 or libfuse2t64. The guest ran under QEMU TCG on an x64 host with one emulated Cortex-A72 CPU and 6 GiB of RAM. Xvfb captured the actual guest display. Electron ran with --disable-gpu --disable-dev-shm-usage.

The released T3 0.0.44 ARM64 payload was repackaged twice using electron-builder 26.15.6: with the PR's toolsets.appimage = "1.0.3" and with the legacy default. This was not a full application rebuild from PR head 8ddfb92b0f5da9868797b45f841c52e77b4fdf43. Both packages contain identical app.asar and Electron executable hashes. Electron is 44.4.2.

Check	Observed result
Legacy control	Initially failed on libz.so. A control-only compatibility link to the installed libz.so.1 exposed the expected libfuse.so.2 failure.
Static runtime	Mounted normally without that shim or extraction mode. Kernel FUSE support was present.
Sandbox	The namespace probe succeeded. The actual Electron command contained no --no-sandbox flag.
Interface	Rendered onboarding, connected to the guest backend, accepted navigation through the steps, and displayed the home screen.
Fresh launch	After a full guest reboot, a fresh process reached backend readiness and rendered the full home screen with the saved state, without another Reload.

Static AppImage SHA-256:

8602af2d741ebbc88b6fbf0cdcdfeb9024423c91f804b174eb027bb47d9a2d6a

Limits and merge assessment

The first cold start exceeded several 60-second backend readiness windows. Once the backend was ready, the renderer initially showed “Still connecting”; clicking Reload led to the connected onboarding interface. No application code or timeouts were changed. The first startup overlapped final package-install work and used temporary scheduling priority adjustments. The post-reboot launch used normal priorities. This slow emulation run is not a performance benchmark.

An X11 window-close command left Electron running, so that attempt was not counted as a process restart. The fresh-launch check uses a full guest reboot and the same AppImage and application state.

This supports the ARM64 packaging fix alongside the earlier x64 VM result. ARM64 updater transitions, tray/notification behavior, and accelerated graphics remain untested. Recommend merge after Julius's review with those limits explicit.

The VM, test server, temporary disks, and SSH keys were removed after collecting the evidence. Screenshots and the evidence archive remain available above.