[Bug]: Can't install t3 via npm on remote debian 13 (VM)

[moda20]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

• create a Debian VM (Linux 6.12.107+deb13-amd64)
• install node 26 via nvm
• run npx --loglevel verbose t3@latest connect
• see the error

Expected behavior

it would install and show the sign in flow

Actual behavior

the t3 version install is stopped at the node-pty

(...)
npm info run msgpackr-extract@3.0.4 install node_modules/msgpackr-extract node-gyp-build-optional-packages
npm info run node-pty@1.1.0 install node_modules/node-pty node scripts/prebuild.js || node-gyp rebuild
npm info run msgpackr-extract@3.0.4 install { code: 0, signal: null }
npm info run node-pty@1.1.0 install { code: 1, signal: null }
npm verbose cwd /home/moda20
npm verbose os Linux 6.12.107+deb13-amd64
npm verbose node v26.8.2
npm verbose npm  v11.19.1
npm verbose exit 1
npm verbose code 1

This doesn't work for the latest preview or nightly as well (at least as of writing this) but they have a different issue :

t3: no T3 Code CLI build is available for this platform (linux-x64).
Supported platforms: darwin-arm64, linux-arm64, linux-x64, win32-arm64, win32-x64.

Impact

Blocks work completely

Version or commit

t3 latest (0.0.40)

Environment

Debina 13 VM amd64 x86

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Thanks for the report — this is a real install blocker on Linux x64, not a wash of #11556.

What we think is going on

There are two different install shapes on npm right now, and you hit both.

1. t3@latest (0.0.40) — node-pty must compile

latest is still the old Node server package (apps/server → node-pty@^1.1.0). That tarball has no Linux prebuilds (darwin/win32 only), so npx t3@latest always runs:

node scripts/prebuild.js || node-gyp rebuild

Your log shows that script running and exiting 1. That is an actual compile/rebuild failure, not npm 12 allow-scripts skipping the script (the closed #7847 / #7475 / #7576 class).

A stock Debian 13 VM usually does not have g++ / make / python3. #11556 confirmed the same node-pty@1.1.0 does build on Node v26.8.2 when g++ is present, so Node 26 itself is probably not the blocker (engines already allow >=24.10). We still want the node-gyp stanza to be sure.

This is related to #11556 (same missing Linux prebuild) but not a duplicate: that issue is linux-arm64 and dies at server start (NodePtyModuleLoadError); yours is linux-x64 and dies during install.

2. t3@preview / t3@nightly — launcher cannot see @t3code/t3-linux-x64

As of #11607, preview/nightly t3 is only a small launcher. The real CLI is an optional dependency @t3code/t3-linux-x64@<same version>. The message:

t3: no T3 Code CLI build is available for this platform (linux-x64).
Supported platforms: darwin-arm64, linux-arm64, linux-x64, win32-arm64, win32-x64.

means require.resolve("@t3code/t3-linux-x64/package.json") failed. linux-x64 is supported; npm did not leave that optional package on disk.

Those platform packages are published for the current tags (0.0.41-nightly.20260914.1722, 0.0.41-preview.20260914.1724, ~206MB, os=linux / cpu=x64). Typical reasons they get dropped: optional-dep install/extract failed (including lifecycle scripts on bundled node-pty), omit=optional, a stale npx cache, or a nightly from the #11607 rollout that listed the dep before the tarball existed.

#10687 (probe native deps before activating updates) is adjacent and does not close this. Default curl | sh cannot save latest yet: v0.0.40 has no CLI archive.

Workaround (Debian VM, no compiler)

Prefer the standalone installer on nightly (needs curl/tar only; no Node, npm, or g++):

curl -fsSL https://t3.codes/install.sh | T3CODE_CHANNEL=nightly sh
# then ensure ~/.local/bin is on PATH
t3 connect

If you want to stick with npx t3@latest:

sudo apt install -y build-essential python3
npx --loglevel verbose t3@latest connect

Please paste (so we can confirm both paths)

node -p "process.platform+'-'+process.arch+' node '+process.version"
which g++ make python3
npm config get omit
# latest: the node-gyp / cc1plus / python error above the `{ code: 1 }` line
# preview/nightly: verbose npx log lines about @t3code/t3-linux-x64
#   (404, omitted optional, EBADENGINE, ENOSPC, etc.)

Maintainer follow-up

1. Next stable needs the feat(release): publish npx t3 as a launcher over per-platform executable packages #11607 launcher and a t3-*-linux-x64.tar.gz so npx t3@latest and default install.sh no longer compile node-pty on Linux.
2. Harden the launcher error when the platform is listed but the optional package is missing (and make sure npx actually lands the ~206MB @t3code/t3-* tarball).
3. Remaining Node-based installs still want the [Bug]: t3 server fails to start on linux-arm64 — node-pty has no prebuild and no working source-build fallback #11556 bump to a node-pty that ships Linux prebuilds (1.2.0-beta.x).
4. docs: make the standalone installer the primary way to get the CLI #11696 (installer-first docs) should mention Linux VMs: latest still needs a compiler until that stable ships.

Accepting as a Linux install bug.

[Geczy]

Additional data point from Linux ARM64, likely separate from the original x64 failure:

@t3code/t3-linux-arm64@0.0.41-nightly.20260915.1780 installs successfully, and the platform package is present. However, the same native binary behaves differently across two ARM64 hosts:

SHA256:
b95a62f0282c30f56bc13cd3e512b57260bd1acffd324923d585beb870f6d2d7

• Ubuntu 22.04, kernel 6.8.0-1047-oracle, glibc 2.35: t3 --version succeeds.
• Oracle Linux 10, UEK kernel 6.12.0-109.67.6.el10uek.aarch64, glibc 2.39: execution fails immediately with:

cannot execute binary file: Exec format error

I also downloaded t3-0.0.41-nightly.20260915.1780-linux-arm64.tar.gz from the GitHub release. Its t3 binary has the same SHA256, so the installer-first route downloads the same executable and does not avoid this failure.

Relevant ELF details:

ELF 64-bit LSB executable, ARM aarch64
interpreter /lib/ld-linux-aarch64.so.1
Start of program headers: 112718032 bytes
Number of program headers: 13

The older Node-based ARM64 nightly runs on the Oracle Linux host, while a later pre-self-contained nightly crashes on the known missing node-pty Linux ARM64 prebuild described in #11556.

This seems distinct from the missing optional dependency reported here: npm successfully installs the ARM64 platform package, but the resulting self-contained executable is rejected by the newer kernel. Would you prefer a separate issue for this kernel-specific ARM64 failure?