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

[View on GitCafe](https://git.cafe/pingdotgg/t3code/pull/23878)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: open

Source repository: Unavailable fork

Source branch: issue-watch/23858

Target branch: main

Head commit: a24df3e992022a51123f466f56834fa8e03154e7

[Discussion and reviews](https://git.cafe/pingdotgg/t3code/pull/23878)

[Commits](https://git.cafe/pingdotgg/t3code/pull/23878/commits?format=markdown)

[Files changed](https://git.cafe/pingdotgg/t3code/pull/23878/diffs?format=markdown)

## Description

---

Closes #23858

## Problem

There is one T3 Code service per user, but each `t3` CLI only knows its own base dir. When the service was installed with `--base-dir`, a CLI run without that flag:

- reported the healthy service as "needs an update or repair" and told you to run `t3 service install`, and
- `t3 service install` then stopped the service and rewrote the unit for `~/.t3`. The service came back on an empty data dir, so every project and thread looked gone.

`t3 service restart` and `t3 uninstall` already leave a unit for another home alone. `install` didn't.

## Fix

- `install` reads the existing unit first. If it names a different `T3CODE_HOME`, it fails with `BootServiceOtherBaseDirError` before downloading, stopping or writing anything. The error says to pass `--base-dir <that home>`, or to run `t3 service uninstall` first to move the service on purpose.
- `status` returns `otherBaseDir` in that case, and `t3 service status` prints "installed for another T3 home" with the base dir instead of offering a repair.

## Evidence

Corex (Linux, systemd user service), using a throwaway user so the real service on the machine was never touched. The service runs with `--base-dir ~/workspace` and has one test project. `served.sh` prints the `T3CODE_HOME` of the running service process and the projects in that home's database.

Before, released `t3@0.1.2` (same service code as `main`), following the issue's steps:

![before](https://github.com/user-attachments/assets/f198fcbc-63cf-417f-9608-bfad971d99a2)

After, this branch's CLI build on the same setup: install refuses, the service keeps serving `~/workspace` with its project (the status screen here is from an earlier revision and also showed the unit path):

![after](https://github.com/user-attachments/assets/fb424329-3581-4c85-8f9b-aa2a7d9333e8)

Test: the existing "restart leaves a service that serves another T3 home alone" case in `bootService.test.ts` now also checks that install fails without running a command or changing the unit, and that status reports the other home. It fails on `main`.

Done by Claude Opus 5.5 in Claude Code (via T3 Code).

🤖 Generated with [Claude Code](https://claude.com/claude-code)