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

Activity

1. moda20

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 14, 2026
2. juliusmarminge commented on Sep 14, 2026

   

   juliusmarminge

   on Sep 14, 2026

   Member

   More actions

   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.

   👍React with 👍1Reacted by Med Kadhem Mansour
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   acceptedfeature request acceptedfeature request accepted

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 14, 2026
4. Geczy commented on Sep 16, 2026

   

   Geczy

   on Sep 16, 2026

   More actions

   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?