fix(server): t3 service install no longer moves a --base-dir service onto an empty ~/.t3#23878

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Propagate non-NotFound unit read failures from BootService.install.

Effect.option converts permission errors from fs.readFileString(unitPath) to None, so the base-directory guard is skipped. If fs.exists(unitPath) returns true, a direct BootService.install call can stop and rewrite the existing unit without checking its base directory.

Treat only a missing unit as absent. Propagate other read failures through BootServiceInstallError.

The normal CLI path calls status before install, and status reads the unit without Effect.option, so this issue is limited to direct service callers.

✅ Addressed in commit ca05875

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Name which t3 service commands leave another home's service alone.

t3 service install and t3 service status leave the service unchanged and name the home it serves. t3 service restart leaves it unchanged but reports that the service is not installed, without naming its home. t3 service uninstall removes the unit even when run with another base directory. Name each command so users do not expect uninstall to leave the service alone.

✅ Addressed in commit ca05875

🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win

Parse quoted systemd assignments before treating T3CODE_HOME as absent.

T3 does not generate the whole-assignment form. However, a valid manually edited unit can use Environment="T3CODE_HOME=/other/home". bootServiceBaseDirOf misses that form, so install can overwrite a service for another home. Accept both forms and add an installation test for the quoted form.

Leaving this out. T3 writes the unit itself and always uses Environment=T3CODE_HOME=.... The quoted form only shows up in a hand-edited unit, and restart, withStopped, t3 update and t3 uninstall read the home with the same parser. Supporting it would change all of them, which is beyond this fix. A unit with no recognised T3CODE_HOME keeps the old repair behaviour, as the PR body says.

@shivamhwp Understood. T3’s renderer uses Environment=T3CODE_HOME=..., which the parser supports. This PR intentionally preserves repair behavior when no T3CODE_HOME is recognized.

I withdraw this finding for this PR. Support for hand-edited assignment formats is a separate enhancement. Would you like a follow-up issue for that?

✅ Review thread resolved.

_{You are interacting with an AI system.}

🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift

Serialize the unit home check and unit write.

BootService.install checks unitPath only once. Two separate CLI processes can both observe that the unit is absent, complete the asynchronous installation work, and later write their own unit configuration. The later writeDurably(unitPath, manager.render(plan)) can replace the service with the other process's baseDir.

Protect the per-user unit installation with a cross-process lock. Re-read and validate the unit home while holding that lock, before changing service files. An in-process semaphore is not sufficient for separate CLI processes.

Leaving this out. Two t3 service install runs at the same moment from different homes race the same way on main, before and after this PR. The issue is a single install run hours after the service was set up, and that is what this guards. A cross-process lock around the unit is a separate change.

@shivamhwp Agreed. This PR guards an existing service against a later install from a different home. The concurrent-install race is a separate concern, not a regression introduced here. I withdraw the cross-process locking requirement for this PR.

Would you like me to open a follow-up issue for that race?

✅ Review thread resolved.

_{You are interacting with an AI system.}

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Use the canonical home comparison for maintenance operations.

install accepts a symlink alias because it compares canonical paths. restart and withStopped still compare path.resolve values, so the alias can differ from the installed target. Both operations can skip the service. withStopped can therefore run its operation without stopping the service.

Reuse otherBaseDirOf while preserving the existing skip behavior for units without T3CODE_HOME.

✅ Addressed in commits 96d8f4d to defd523

Fixed in defd523f04: restart and withStopped now use otherBaseDirOf, so a symlinked home counts as the same one there too. Units without T3CODE_HOME are still skipped. The restart test now also covers the alias.

@shivamhwp The supplied code confirms that restart and withStopped now use otherBaseDirOf for canonical home comparison. Both still skip units without T3CODE_HOME. This addresses the finding.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

✅ Review thread resolved.

_{You are interacting with an AI system.}