Sign up
View stargazersSign up

[Bug]: Server update action suggests npx relaunch for a hand-started server installed by the t3 install script#29460

opened8d agobyHhieu-lee

Before submitting

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

Area

  • apps/web
  • apps/server

Steps to reproduce

  1. On a Linux host, install t3 with the install script, so ~/.local/bin/t3 is a symlink into ~/.t3/runtime/versions/<version>/t3.
  2. Start the server by hand, for example t3 serve --host 127.0.0.1 --port 3773 in tmux. That host has no systemd, so t3 up can't install the background service.
  3. Update a client (desktop or web) to a newer release, then open that environment's server update action.

Expected behavior

The server can't update itself, so the client should offer a manual command that updates the installed t3:

sh
1t3 update --base-dir ~/.t3 <client-version>

followed by restarting the server with its usual options.

Actual behavior

The server reports no installation kind for a launcher-started runtime, so the client falls back to Copy relaunch command with npx t3@<client-version>. That command:

  • needs Node on the host, which a host that only has the downloaded runtime may not have;
  • runs a separate npx copy and leaves the installed t3 launcher on the old version, so the next restart through the user's own launcher script starts the old version again.

Update everything also lists this host as "needs a manual update" without the right command. In practice the host stays behind indefinitely. Our workspace stayed on 0.1.3 while the desktop app moved to 0.1.6. The desktop's SSH launch had already downloaded the 0.1.6 runtime to the host, but it reused the running external 0.1.3 server, as designed.

Impact

Major inconvenience. Hand-started remote servers fall behind silently, and the suggested fix doesn't update them.

Version or commit

Client 0.1.6; host server 0.1.3 (main at edc37c96c8 has the same behavior).

Environment

Linux ARM64 devcontainer (no systemd, docker-init as PID 1), t3 installed by the install script, server started in tmux through ~/.local/bin/t3. Reached via desktop-managed SSH and T3 Connect.

Workaround

Run t3 update <version> on the host, then restart the server by hand.

Nnexus-cw7d ago
Synced from GitHub

Same issue here, confirmed on another non-systemd host, with a working update path.

Environment

  • Host: Linux x64 (Fedora kernel 7.2.13), running as a pod in k3s. PID 1 is tail, so there's no systemd and t3 service install isn't available.
  • t3 installed by the install script: ~/.local/bin/t3 → ~/.t3/runtime/versions/<version>/t3
  • Server started by a hand-written restart loop: bash -lc 'while :; do t3 serve --host 127.0.0.1 >>…/croft-serve.log 2>&1; sleep 5; done'
  • Server 0.1.5, latest 0.1.6. Accessed through the T3 Code web UI.

What happened

  • The update button said the host had to be updated manually ("Update T3 Code on croft-0 manually; it cannot update itself.").
  • The 0.1.5 server's /.well-known/t3/environment response had neither serverSelfUpdate nor serverInstallation. That matches resolveServerSelfUpdateCapability returning null when the server is neither desktop-managed nor launcher-managed, and the client then falls back to the generic npx t3@<version> command. Running that command wouldn't have helped: the restart loop runs ~/.local/bin/t3, so the server would have come back on 0.1.5.

What fixed it

sh
1t3 update 0.1.6 # installs runtime, repoints ~/.local/bin/t3
2kill <server pid> # restart loop brings it back on 0.1.6

/.well-known/t3/environment now reports serverVersion: "0.1.6". The CLI also printed a helpful hint after updating ("A server started by hand is still running … Stop it and start it again to pick up 0.1.6."). Suggesting t3 update <version> plus a restart in the UI, as this issue's Expected section says, would have been the right guidance.

Investigated with t3 triage by Claude Opus 5.5 (Claude Code).