Windows ARM64 Nightly updates omit Linux ARM64 WSL backend binaries

[DamianReeves]

Summary

On a Windows ARM64 laptop, every T3 Code Nightly update currently loses the Linux ARM64 native modules required by the WSL backend. The WSL backend then fails to start until the native modules are rebuilt and copied into the packaged backend.

Environment

• Host: Windows 11 on ARM64 hardware
• WSL: WSL2, Ubuntu-26.04 LTS, aarch64
• T3 Code: Nightly builds observed: 0.0.34-nightly.20260823.1170, 0.0.35-nightly.20260826.1195, 0.0.36-nightly.20260827.1207, 0.0.37-nightly.20260829.1218, 0.0.38-nightly.20260901.1250, 0.0.39-nightly.20260903.1273
• Node in WSL: Node 24 LTS via mise

Actual behavior

After an update, Settings > Connections reports:

WSL backend couldn't start: WSL node-pty unavailable: WSL support is missing from this T3 Code build: the packaged Linux node-pty binary was not included.

The backend does not start even though WSL itself is healthy and the distro can launch normally.

Reproduction

1. Use T3 Code Nightly on Windows ARM64.
2. Enable the WSL backend and select an ARM64 WSL2 distro.
3. Update T3 Code Nightly.
4. Reopen T3 Code and enable/select the same distro.
5. The WSL backend fails because the packaged backend has no node-pty/prebuilds/linux-arm64/pty.node.
6. Repeat after each subsequent update. The failure recurs.

Workaround currently required

For each update, I have to stop T3 Code, rebuild node-pty for Linux ARM64 inside WSL, and copy the resulting pty.node plus ARM64 ffi-rs and fff packages into both:

• the extracted WSL server tree under %USERPROFILE%\\.t3\\userdata\\wsl-server-tree\\<version>
• resources\\server.asar.unpacked\\node_modules in the installed T3 Code directory

The workaround succeeds consistently. The repaired binary is 81,112 bytes and the backend starts normally afterward.

Suspected cause

The Windows artifact appears to be missing Linux ARM64 WSL prebuilds. The release workflow currently describes a Linux x64 WSL node-pty build, but Windows ARM64 requires a Linux ARM64 binary because the WSL backend runs under the distro's Linux Node, not the Windows host Node. The same architecture handling may also be needed for the Linux ARM64 ffi-rs and fff packages.

Expected behavior

The Windows ARM64 artifact should either:

1. ship Linux ARM64 WSL prebuilds and matching ARM64 native dependencies, or
2. detect the WSL architecture during first launch and perform a supported, automatic native build with a clear progress/error path.

A release/update should not silently replace a working WSL backend with an artifact that cannot start on the same machine.

Additional notes

The current error message points at a missing packaged binary, so this is not a distro-selection, WSL-service, or project-path issue. A release CI check that launches the packaged WSL backend on aarch64 would catch this before publishing ARM64 Windows builds.