SSH setup reports a missing compiler when the requested nightly is not yet published

[neronlux]

What happened

Desktop SSH connection failed with ETARGET for t3@0.0.39-nightly.20260905.1286. The error then claimed the package was installed without an executable and recommended installing a C toolchain.

Diagnosis

The connection attempt occurred before npm published the requested version:

• GitHub release: September 5, 2026, 09:51:30 UTC.
• Failed npm invocation: 09:57:00 UTC.
• npm publication: 09:58:48 UTC.

In packages/ssh/src/tunnel.ts, require_installed_t3_cli suppresses the npm command’s failure with || true, then prints the native-build diagnostic whenever no executable path is returned. This also misclassifies package-version resolution failures.

Source inspected: commit bc8584bf8e967ecc1cd215d42bd7a47faf51a862 (nightly 1285).

Steps to reproduce

1. Use a desktop nightly during the interval before its corresponding npm package is published.
2. Connect to an SSH environment that needs to install that exact version.
3. Observe npm’s ETARGET followed by misleading compiler-installation advice.

These steps describe the observed failure; a fresh reproduction was not performed.

Version

Requested remote package: 0.0.39-nightly.20260905.1286.
Triage CLI: 0.0.39-nightly.20260905.1285.

Environment

Remote: Linux x64, Node 22.23.2, npm 11.17.0. Desktop connecting over SSH; desktop OS not collected.

Evidence

npm error code ETARGET
npm error notarget No matching version found for t3@0.0.39-nightly.20260905.1286.
Remote host installed t3@0.0.39-nightly.20260905.1286 but npm produced no t3 executable, which usually means a native dependency (node-pty) failed to build.

Related issues

No matching issue found in searches for ETARGET, "npm produced no", and nightly SSH npm.

Fix applied or workaround

Confirmed the exact package is now published and advised reconnecting. Successful reconnection has not yet been confirmed. No installation or service changes were made.

Filed by

Codex (GPT-6), via T3 triage.

[juliusmarminge]

Triage

Confirmed. Desktop SSH asks the remote host for the exact packaged app version (t3@0.0.39-nightly.20260905.1286). When that version is not on npm yet, npx/npm exec fails with ETARGET, but require_installed_t3_cli treats “no t3 on PATH” as a successful install with a failed node-pty build.

What happens

Packaged (non-dev) desktop builds pin the remote CLI to the running app version:

// packages/ssh/src/command.ts
if (!input.isDevelopment && PUBLISHABLE_T3_VERSION_PATTERN.test(appVersion)) {
  return `t3@${appVersion}`;
}

Nightly 0.0.39-nightly.20260905.1286 matches that pattern, so SSH does not fall back to t3@nightly. The remote runner then preflights install like this:

# packages/ssh/src/tunnel.ts — REMOTE_RUNNER_SCRIPT
require_installed_t3_cli() {
  T3_CLI_PATH="$("$@" -- sh -c 'command -v t3' || true)"
  if [ -n "$T3_CLI_PATH" ]; then
    return 0
  fi
  printf 'Remote host installed %s but npm produced no t3 executable, which usually means a native dependency (node-pty) failed to build. …' …
  return 1
}

|| true was added in #5132 so a successful npx --yes that exits 0 with no t3 binary (the real missing-compiler / node-pty case) still fails loudly. It also swallows real npm failures. Empty T3_CLI_PATH then always prints the compiler message, including for ETARGET.

The reporter’s timeline matches that race: GitHub release 09:51:30 UTC, failed npm 09:57:00, npm publication 09:58:48. Evidence is consistent (ETARGET + the “installed … no t3 executable” line).

Suggested fix

Keep the #5132 empty-bin check, but branch on the install exit code:

1. Capture npm/npx status instead of || true.
2. If the command failed, report that the package could not be installed and leave npm’s stderr as the cause. Do not claim the package was installed or recommend a C toolchain.
3. Emit the node-pty / compiler message only when the command exits 0 and still produces no t3 executable.

packages/ssh/src/tunnel.test.ts currently only asserts that the compiler string is present. Cover the ETARGET / non-zero-install path so this cannot regress.

Retrying or falling back to t3@nightly during the GitHub-release → npm-publish window is a separate product decision. The user-facing bug here is the misattribution.

Workaround

Reconnect after the exact version exists on npm. No remote toolchain change is required.

Surfaces

• Desktop SSH install of a pinned nightly/stable t3@<exact version>
• Shared remote runner in packages/ssh (also used if other clients adopt the same script)
• Not a provider, contracts, or mobile issue

[juliusmarminge]

Fixed by #10088 (merged to main).

[juliusmarminge]

Fixed on main by #10088, merged as 39802c06 on September 5, 2026.

I reproduced the misleading diagnostic with the production-generated script and real /bin/sh, using controlled failing installers for both npx and npm exec. The fix checks the installer's exit status, preserves npm's stderr, and reports installation failure instead of recommending a compiler. The successful-install/no-executable safeguard remains. All 36 focused tests pass, including an independent run, and current-head CI passed.

Closing the diagnostic bug. This does not change package publication timing or version selection, and I did not reproduce a complete SSH reconnect. If a current build still prints the wrong diagnostic, please open a new issue with its version and sanitized error output.

Verified by GPT 6 Astra via Codex in T3 Code.