fix(server): stop npx service updates from silently leaving the old server running

[t3dotgg]

Updating T3 Code with npx t3@nightly connect failed on my machine. It downloaded the new version, then reported "Could not set up the T3 Code background service" and left the old server running. Retrying and rebooting did not help.

The installer looked for service-launcher.mjs next to process.argv[1]. Under npx that path is the node_modules/.bin/t3 symlink, and Node keeps the symlink path in argv[1], so it searched a bin directory that has no launcher. The read failed before systemd was stopped, so the update aborted with the previous version still serving.

It now reads the launcher from the pinned runtime the installer just prepared and verified, which is the same place the version is staged for every install path.

Verified on bb-1: the repair completed, systemd now runs the launcher with the new server as its child, and the machine came back reachable over the relay.

Made by Claude Opus 5 in Claude Code.

---

Note

Medium Risk
Changes install-time file resolution for the systemd background service on Linux; wrong paths would break updates, but scope is limited to boot service setup and covered by a new test.

Overview
Fixes background service setup when the CLI runs via npx, where the installer used to look for service-launcher.mjs beside process.argv[1] (often a node_modules/.bin symlink with no launcher). That read failed before systemd was updated, so updates aborted and the old server kept running.

BootService now defaults the launcher source to the pinned runtime directory prepared and verified during install—the same staging path used for every install flow. cliEntryPath and HostProcessArguments are removed from BootServiceHost; an explicit launcherSourcePath override remains.

A test confirms install copies the launcher from the pinned runtime when no override is set.

^{Reviewed by Cursor Bugbot for commit 747860a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix npx service updates leaving old server running by resolving launcher from pinned runtime

When host.launcherSourcePath is not provided, the launcher is now copied from the pinned runtime directory (service-launcher.mjs alongside the pinned runtime entry) rather than from the host CLI entry path directory. This fixes a bug where npx service updates would silently leave the old server running because the wrong launcher was used.

• Removes cliEntryPath from the BootServiceHost interface in bootService.ts and stops reading HostProcessArguments
• Adds a test case in bootService.test.ts that verifies the launcher is copied from the pinned runtime directory during install

^{Macroscope summarized 747860a.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a46a7413-eb39-43db-a32a-17b2f17c1ca9

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved 747860a

This is a focused bug fix that changes path resolution for the service launcher source from the ephemeral CLI entry path to the pinned runtime path. The change is small, includes a test, and addresses a clear issue with npx-based updates. Low risk.

^{You can customize Macroscope's approvability policy. Learn more.}