[Bug]: macOS service pins Homebrew Node Cellar path, making Node upgrades unsafe #11054

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

1. On an Apple Silicon Mac, install Node with Homebrew and invoke Node through Homebrew's stable path:

   command -v node
   node -p 'process.execPath'

   On my machine this prints:

   /opt/homebrew/bin/node
   /opt/homebrew/Cellar/node/26.8.1/bin/node
   

   /opt/homebrew/bin/node is a symlink managed by Homebrew. process.execPath is the resolved, version-specific executable.

2. Install or update the T3 background service from that environment. I reproduced the generated configuration after:

   npx t3@0.0.41-nightly.20260909.1439 service update

3. Inspect the executable stored in the LaunchAgent:

   plutil -extract ProgramArguments.0 raw \
     "$HOME/Library/LaunchAgents/com.t3tools.t3code.service.plist"

4. The plist contains the resolved Cellar path:

   /opt/homebrew/Cellar/node/26.8.1/bin/node
   

5. A normal Homebrew Node upgrade can repoint /opt/homebrew/bin/node and eventually remove the old keg. At that point the LaunchAgent still references the old version-specific path.

I did not intentionally remove the currently running Node keg just to force an outage on this host. The deterministic repro here is the generated service definition retaining a path whose lifetime is tied to one Homebrew keg.

Expected behavior

A T3 background service installed with Homebrew-managed Node should remain startable across a routine Node upgrade, or the service lifecycle should otherwise make this dependency and the required maintenance explicit before the old executable disappears.

Actual behavior

The generated LaunchAgent stores the resolved Cellar path. The service works while that keg exists, but a later restart can fail once Homebrew removes it, even though the normal node command continues to work through /opt/homebrew/bin/node.

There is a related runtime concern: the stable service launcher also starts managed T3 runtimes through its own process.execPath. If the launcher remains alive while Homebrew replaces and removes its Node keg, a later managed-runtime handoff may also try to use the removed executable.

Impact

Major degradation or frequent failure

Version or commit

Observed in 0.0.41-nightly.20260909.1439; the relevant behavior is also present on main at d29c56a5c404cb0f58d3b2ac41762fa0d0ac28d4.

Environment

macOS 26.6.2 (Apple Silicon), Homebrew Node 26.8.1, npm 11.19.0, T3 background service managed by launchd

Logs or stack traces

$ ls -l /opt/homebrew/bin/node
/opt/homebrew/bin/node -> ../Cellar/node/26.8.1/bin/node

$ node -p 'process.execPath'
/opt/homebrew/Cellar/node/26.8.1/bin/node

$ plutil -extract ProgramArguments.0 raw \
    "$HOME/Library/LaunchAgents/com.t3tools.t3code.service.plist"
/opt/homebrew/Cellar/node/26.8.1/bin/node

Investigation notes

I inspected the installed package and current source to understand whether this was only a local plist change.

• bootService.ts builds the service plan with nodePath: host.execPath, and the macOS renderer writes plan.nodePath into ProgramArguments[0].
• serviceLauncher.ts starts a managed runtime with spawn(process.execPath, ...).
• These two observations are consistent with the generated plist and process tree on my host.

Relevant source on the inspected commit:

• t3code/apps/server/src/cloud/bootService.ts

  Lines 570 to 572 in d29c56a

  	const plan: BootServicePlan = {
  	nodePath: host.execPath,
  	launcherPath,

• t3code/apps/server/src/serviceLauncher.ts

  Lines 397 to 408 in d29c56a

  	}
  	if (this.#stopping) return;
  	const paths = runtimePaths(this.#baseDir, version);
  	const context: ServiceLauncherContext = {
  	protocol: SERVICE_LAUNCHER_PROTOCOL,
  	childVersion: version,
  	...(update === undefined ? {} : { update }),
  	};
  	const child = NodeChildProcess.spawn(process.execPath, [paths.entryPath, "serve"], {
  	env: { ...process.env, [SERVICE_LAUNCHER_CONTEXT_ENV]: JSON.stringify(context) },
  	stdio: ["inherit", "inherit", "inherit", "ipc"],
  	});

I may be missing an intended assumption about how Node is provisioned for the background service. I am reporting the lifecycle mismatch rather than proposing a specific implementation. Preserving an upgrade-stable executable reference, resolving the current runtime at launch, or explicitly coordinating service maintenance with Node upgrades may have different trade-offs that are clearer to the maintainers.

Workaround

I currently keep a locally managed LaunchAgent configuration and check it after t3 service update. This avoids relying on the generated Cellar path, but I do not consider the local configuration a recommendation for the upstream design.