Home-ownership dialog gives the same advice for an old and a current background service, and never mentions turning off Local environment#22821

Same issue here, reached through the t3 update path instead of uninstall and reinstall.

Sequence

1. The desktop app (Nightly) updated to 0.1.2-nightly.20261021.3473. The background service was still on 0.0.38.
2. The app showed "This T3 home is unavailable" and quit (OlderBootServiceError, code 78).
3. I ran t3 update, as the dialog suggests. The service updated to 0.1.2-nightly.20261021.3473 and restarted.
4. I reopened the app and got the same dialog. This time the cause was ServerAlreadyRunningError, because the updated service holds the lock.

So the dialog's first suggestion (t3 update) also leads into the loop. It fixes the first error, but then the second error shows the same text.

Evidence (server-child.log, home path redacted)

After the update, the service was healthy: /.well-known/t3/environment reported serverVersion: 0.1.2-nightly.20261021.3473.

Environment macOS 26 (darwin arm64). Desktop app T3 Code (Nightly) 0.1.2-nightly.20261021.3473. Background service through launchd, 0.0.38 then 0.1.2-nightly.20261021.3473. Desktop serverExposureMode: network-accessible, Tailscale Serve on. Triage CLI 0.1.1, not involved.

Added by Claude Code (Claude Opus 5.5) through t3 triage.

I also encountered this after updating the desktop app from 0.1.0 to 0.1.1 on one of two devices, while coding.

The app displayed "This T3 home is unavailable" and would not open. Diagnosis identified the older-background-service case described in this issue.

After backing up the coding work and session history, removing the obsolete background service allowed the desktop app to start again with the existing tasks preserved. The desktop now runs the server; reconnection from the second device has not yet been verified.

Please consider detecting this upgrade conflict before the desktop becomes inaccessible, and providing a recovery action that preserves ongoing work and explains the choice between a desktop-managed server and an always-on background service.

This is a report for the released 0.1.1 build, not a reproduction against current main.

Confirmed the older-service startup failure on Linux with the desktop installed through yay/AUR.

Environment

• CachyOS, Linux x64, kernel 7.2.11-1-cachyos
• AUR package: t3code-nightly-bin 0.1.2_nightly.20261021.3499-1
• Desktop version: 0.1.2-nightly.20261021.3499
• Older background service recorded version 0.0.33

What happened Launching T3 Code from the app drawer displayed “This T3 home is unavailable” and exited. The backend log repeatedly recorded OlderBootServiceError, exit code 78.

Diagnosis The old systemd user service was enabled but failed with 203/EXEC: its configured Node executable no longer existed. The desktop still refused startup because that older service remained configured.

Recovery Ran:

The command succeeded, and systemd subsequently reported LoadState=not-found. After relaunching the desktop, /.well-known/t3/environment returned HTTP 200 with serverVersion: 0.1.2-nightly.20261021.3499. The existing database remained in place.

This confirms the older-service case and recovery on the released nightly. The current-service conflict case and current main were not tested.

Produced by Codex (GPT-6.1-sol) through t3 triage.

Same issue here, macOS desktop Nightly, OlderBootServiceError case.

Setup

• Desktop: T3 Code (Nightly) 0.1.2-nightly.20261022.3541, updated in-app just before the failure.
• Background service: launchd com.t3tools.t3code.service, running ~/.t3/runtime/versions/0.0.45/t3 __service-launcher (installed alongside the 0.0.45 Alpha app). service-state.json still showed activeVersion: 0.0.45, although a 0.1.2 runtime had been staged under runtime/versions/0.1.2.
• macOS 26 (Darwin 25.6.0), arm64.

Evidence (server-child.log, home path redacted)

Recovery I didn't need the service, so I removed it rather than updating it (updating would have led to the ServerAlreadyRunningError loop described above):

After a fresh launch, the desktop backend started on port 3773 with the existing database intact.

One extra problem along the way: after the dialog, the app process didn't quit. It stayed running with no window, ignored SIGTERM, and reopening the app did nothing. I filed that separately as #23843.

Filed via t3 triage by Claude Code (Claude Opus 5.5).

A third route to this dialog: the error is ServerAlreadyRunningError, but the owner is a pre-lock server that no T3 service manages.

Setup. macOS 27 arm64, desktop T3 Code (Nightly) 0.1.2-nightly.20261021.3499. A hand-written LaunchAgent with its own label (KeepAlive) ran t3 serve from the npm package t3@0.0.31. That build writes server-runtime.json without ownerId and never takes the server-owner.sqlite lock.

What happened. The backend exited 78 with ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata, through the legacy-record check (legacyOwnerIsLive). OlderBootServiceError never fired, because olderBootServiceHome only reads com.t3tools.t3code.service and runtime/service-state.json. PR #19715 lists that layout as out of scope. The same applies to a pre-lock server started from a terminal, tmux, or a custom systemd unit.

Why it matters for the fix here. Splitting the text by error class would show this user the current-service advice ("turn off Local environment and pair"). Pairing a current desktop with a 0.0.31 server is not supported (#21375), and that server could not load threads anyway (PersistenceDecodeError on 206 messages with role "reasoning" written by newer builds). t3 update and t3 service uninstall cannot touch a plist they did not write. A legacy record with a live pid is better treated as an older server. The record already has pid, port and startedAt, so the dialog could name the process to stop; #23707 asked for that too. The startup check in #22984 has the same gap: a pre-lock server that answers /.well-known/t3/environment (0.0.31 does) counts as a healthy owner and gets the pairing advice.

Workaround. launchctl bootout gui/$(id -u)/<label>, move the plist out of ~/Library/LaunchAgents, then relaunch the app.

Side note: the duplicate pointer on #23707 names #22821, which is a keybinding PR; it probably means this issue.

Same failure on a third path: the desktop app updated first, and the background service was updated afterwards.

Sequence

1. The macOS desktop app (Beta) updated to 0.1.2 while the launchd service was still on a release from before the ownership lock.
2. The app showed "This T3 home is unavailable" and quit. server-child.log recorded four OlderBootServiceError exits with code 78, between 13:39 and 13:40.
3. The service updated to 0.1.2 and restarted at 13:43. service-state.json has activeVersion: 0.1.2, and server-runtime.json has serviceManaged: true.
4. Reopening the app produced the same dialog. server-child.log now recorded ServerAlreadyRunningError, code 78.

The dialog's own advice (t3 update, t3 service uninstall) does not apply once the service is current, as the issue says. The app quits before Settings is reachable, so the user can't turn off Local environment.

Workaround that worked: setting "localEnvironmentEnabled": false in ~/.t3/userdata/desktop-settings.json and relaunching. The process started and no further code-78 exit was logged.

Version: desktop 0.1.2 (Beta, release tag v0.1.2) and service 0.1.2. Environment: macOS arm64, desktop app plus launchd service (com.t3tools.t3code.service).

Produced by Claude (claude-sonnet-5-5) in Claude Code, via the T3 Code triage playbook.

Linux confirmation on T3 Code Nightly 0.1.3-nightly.20261023.3592, with the desktop app and a systemd user background service on the same machine. Opening the desktop app shows “This T3 home is unavailable” and exits. The desktop backend log records ServerAlreadyRunningError and exit code 78 on repeated launches. The service is configured for the same T3 home and its log records it listening on port 3773; the desktop attempted port 3774. The desktop setting localEnvironmentEnabled is absent, so it uses the default of true. The user wants to keep both the desktop app and background service, without maintaining a manual recovery procedure. The dialog still offers service update or reinstall advice despite the service and desktop being on the same current Nightly version.

Investigated with Codex (GPT-6) via t3 triage.

Same ServerAlreadyRunningError loop on macOS, with the desktop app and the service both on current nightlies. t3 update did not help.

Setup

• Desktop: T3 Code (Nightly) 0.1.3-nightly.20261024.3617
• Background service: launchd com.t3tools.t3code.service, on 0.1.3-nightly.20261024.3604 when it failed. It was installed the day before, and RunAtLoad started it at login.
• macOS (Darwin 25.3.0), arm64, Node 24.22.0
• desktop-settings.json has no localEnvironmentEnabled, so it defaults to true

What happened

1. At login, the service started and took ~/.t3/userdata on port 3773.
2. When the desktop app opened, its port scan found 3773 busy. It chose 3774 and started its own backend on the same T3 home, which exited with code 78.
3. I ran t3 update --yes as the dialog suggests. The service moved to 0.1.3-nightly.20261025.3669 and restarted. The desktop app still started its own backend on 3774 and failed again at 16:10:08Z.

Every earlier desktop launch in desktop.trace.ndjson picked 3773, because the service wasn't running yet. The desktop app never tries to attach to a running service. It always starts its own backend.

Evidence (server-child.log, home path redacted)

Workaround applied: t3 service uninstall. That gives up the always-on service.

Filed by Claude Code (Claude Opus 5.5) via t3 triage.

Follow-up: after t3 service uninstall, the desktop app (0.1.3-nightly.20261024.3617) started its own backend on port 3773 with no errors, and the app opens normally. The DB and threads were untouched. This confirms the conflict was between the service and the desktop's own local backend, not a stale lock.

Filed by Claude Code (Claude Opus 5.5) via t3 triage.