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

What happened

After updating the macOS desktop app (Nightly), it showed "This T3 home is unavailable" and quit. A v0.0.45 background service was installed. Following the dialog's advice (t3 service uninstall, then t3 service install from a current CLI) replaced it with a v0.1.1 service, but reopening the app showed the identical dialog again. The user wanted both the desktop app and the background service (for relay and mobile access).

Diagnosis

Two different causes produce the same dialog:

OlderBootServiceError: a pre-ownership-lock service is set up for the T3 home. Uninstalling or updating it is the right fix.
ServerAlreadyRunningError: a current service owns the T3 home. Uninstalling and reinstalling cannot help here.

Both exit with code 78, and DesktopBackendManager routes both to onStateDirOwned, which shows one combined message in DesktopBackendPool.ts and calls app.quit. In case 2, the dialog's main advice sends the user in a loop.

The supported setup for desktop plus background service (per #20250 and #9194) is to turn off Settings > Connections > Local environment and pair with the service. The dialog never mentions it, and because the app quits before the window opens, the setting can't be reached without stopping the service first or editing desktop-settings.json (localEnvironmentEnabled: false) by hand.

Suggested direction: show different text for each cause, and in case 2, offer to turn off the local environment (and restart) instead of only quitting.

Steps to reproduce

Install a background service with a current CLI: npx t3@latest service install.
Open the desktop app with Local environment on (the default).
The dialog suggests uninstalling and reinstalling the service, then the app quits.
Follow that advice and reopen the app. The same dialog appears.

Version

Desktop: 0.1.2-nightly.20261021.3457. Background service: 0.0.45, replaced during triage with 0.1.1. Triage CLI: 0.1.1.

Environment

macOS 27.2 (arm64), desktop app (Nightly), background service via launchd.

Evidence

From server-child.log:

21:14:43 ERROR OlderBootServiceError: A T3 Code background service set up for ~/.t3 may still run a release without the ownership lock. ... code=78
21:54:37 ERROR ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped. ... code=78

Both were followed by the same "This T3 home is unavailable" dialog.

Related issues

#20250 (desktop quits instead of offering to connect; closed as not planned), #9194 (Local environment toggle), #18515 (reduced local features in client mode), #8114.

Fix applied or workaround

Set localEnvironmentEnabled: false in ~/.t3/userdata/desktop-settings.json while the app was closed, reopened the app, and paired it with the service using t3 pair. The app now opens and connects.

Filed by

Claude Code (Claude Opus 5.5) via t3 triage.

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

Sequence

The desktop app (Nightly) updated to 0.1.2-nightly.20261021.3473. The background service was still on 0.0.38.
The app showed "This T3 home is unavailable" and quit (OlderBootServiceError, code 78).
I ran t3 update, as the dialog suggests. The service updated to 0.1.2-nightly.20261021.3473 and restarted.
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)

13:53:04 ERROR OlderBootServiceError: A T3 Code background service set up for ~/.t3 may still run a release without the ownership lock. ... code=78
13:55:17 ERROR ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. ... code=78

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:

t3 service uninstall --base-dir ~/.t3

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)

22:54:55 ERROR OlderBootServiceError: A T3 Code background service set up for ~/.t3 may still run a release without the ownership lock. ... code=78
22:55:35 ERROR OlderBootServiceError: ... code=78

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):

npx t3@latest service uninstall --base-dir ~/.t3

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

The macOS desktop app (Beta) updated to 0.1.2 while the launchd service was still on a release from before the ownership lock.
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.
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.
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

At login, the service started and took ~/.t3/userdata on port 3773.
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.
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)

15:52:47Z backend child pid=5618 port=3774
ERROR ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped.
    at acquireServerOwnership (Nightly)
    at server.runServerCommand (binCli-CG7YtO-F.mjs:344844:16)
backend child exit code=78
16:10:08Z  same error, pid=7878 port=3774 (service already updated to 0.1.3-nightly.20261025.3669)

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.

Linux confirmation of the current-service case (ServerAlreadyRunningError), with the desktop app and service on the same nightly. Updating the service did not help.

Setup

Arch Linux x64, Hyprland. Desktop: AppImage, nightly channel, 0.1.3-nightly.20261027.3754
Background service: systemd user unit t3code.service for the default T3 home ~/.t3, with the T3 Connect managed tunnel enabled
desktop-settings.json has no localEnvironmentEnabled, so it defaults to true

Sequence (local time, UTC−5)

Oct 26, 20:47–20:51: the service was on 0.1.3-nightly.20261025.3692. Three desktop launches each showed "This T3 home is unavailable" and quit. This was before the AppImage auto-update to 20261027.3754 (AppImage mtime Oct 27 00:56).
Oct 28: the desktop was on 20261027.3754 and the service was still on 20261025.3692 (service-state.json activeVersion). Same dialog at 20:04. t3 service status from the new CLI said the service needed an update or repair.
20:08: t3 service install rewrote the unit's ExecStart to runtime/versions/0.1.3-nightly.20261027.3754/t3 __service-launcher. The service restarted on 3773, and the launcher pruned the 20261025.3692 runtime.
20:12:34 and 20:12:41: two more desktop launches failed the same way, with desktop and service now on the identical build.

Each time, the desktop trace shows selected backend port via sequential scan → port 3774 (3773 is held by the service) → the child exits 78:

ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped.
    at acquireServerOwnership (…/apps/server/dist/binCli-*.mjs)
backend child process failure output end  pid=… code=78

So the version gap the user first suspected was a red herring. Making the service match the desktop is exactly what the dialog's t3 update / t3 service install advice achieves, and it leads straight back into the loop. The only change that matters is localEnvironmentEnabled, which the user can't reach because the app quits before opening a window. DesktopBackendPool.ts onStateDirOwned is unchanged on main as of today.

Also seen: after the 20:12:41 failure, the desktop main process was still alive with no backend (possibly #23843).

Workaround: set "localEnvironmentEnabled": false in ~/.t3/userdata/desktop-settings.json while the app is closed, reopen, and pair with the service.

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

Follow-up: the workaround worked for this user. With the desktop app closed, I set "localEnvironmentEnabled": false in ~/.t3/userdata/desktop-settings.json. On reopening, the app showed "This computer is off" instead of the dialog. Pairing it with the running service (t3 pair from the service's runtime, then adding http://127.0.0.1:3773 as a connection) brought back the existing projects and threads. Desktop and service are both on 0.1.3-nightly.20261027.3754, Arch Linux, AppImage plus systemd user service.

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

Confirmed a background-service startup conflict on CachyOS with the AUR nightly desktop package.

What happened

Every normal desktop launch showed “This T3 home is unavailable.” Killing the T3 process in btop and immediately reopening the desktop allowed it to start.

Environment

CachyOS, Linux x64, kernel 7.3.0-5-cachyos
Desktop package: t3code-nightly-bin 0.1.6_nightly.20261029.3892-1
Desktop connecting to its local server on the same machine
Triage CLI: 0.1.5

Evidence and diagnosis

The enabled systemd user unit, t3code.service, was configured to launch T3 from ~/.t3/runtime/versions/0.0.31/, using the same T3 home as the desktop. It had Restart=always and RestartSec=5, consistent with the brief window in which the user's workaround succeeded. The running service version was not independently verified.

Desktop backend failures on October 29 recorded:

ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata.
Stop that server, or use a separate T3 home and pair with it, then retry.
No server was stopped.

The backend exited with code 78.

Verified recovery

The user ran:

npx t3@latest service uninstall --base-dir "$HOME/.t3"

It returned:

Removed the T3 Code service.

The user then reopened the desktop normally and confirmed it started successfully.

Drafted by Codex (GPT-6) via t3 triage.

Another case of this on macOS, with one detail I haven't seen here yet: a reboot flips which server wins the T3 home. The service then serves an 8-day-old build and the desktop app can't start.

What happened

Oct 22: the background service (launchd, com.t3tools.t3code.service) was installed while the Nightly desktop app already owned ~/.t3. The service launcher exited 78, logged [service-launcher] Another T3 Code server owns this T3 home, and went idle.
Oct 22 to Oct 30: the desktop app was the real server. The idle service never updated, so the launchd unit and service-state.json stayed on 0.1.2-nightly.20261022.3512.
Oct 30, 16:43: the desktop app self-updated to 0.1.6-nightly.20261030.3940.
Oct 30, 20:19:28: the Mac rebooted. launchd (RunAtLoad) started the old 0.1.2 service at 20:20:11, and it took the ownership lock.
20:21:06: the desktop app's backend failed with ServerAlreadyRunningError (exit 78). The app showed "This T3 home is unavailable" and quit.

So the dialog's ordering problem has a time bomb: while the desktop app holds the lock, an installed service looks harmless and silently goes stale. The next reboot hands the home to the stale service.

Diagnosis (source at `v0.1.6-nightly.20261030.3940`)

apps/server/src/serviceLauncher.ts #idleWhileStateDirOwned: an idle service never retries or updates. Nothing tells the user it is idle.
apps/desktop/src/backend/DesktopBackendPool.ts:176: onStateDirOwned shows the combined message and calls app.quit. It does not point at Local environment, which is the supported fix for this setup.

Workaround that worked

t3 update --yes moved the service to 0.1.6-nightly.20261031.3956.
With the app closed, added "localEnvironmentEnabled": false to ~/.t3/userdata/desktop-settings.json.
Reopened the app. No dialog, no backend start on 3774. Then paired with the service through t3 pair.

Environment

Version the bug happened on: desktop app 0.1.6-nightly.20261030.3940, background service 0.1.2-nightly.20261022.3512. Triage CLI: 0.1.6-nightly.20261030.3940.
macOS 27.0.0 (darwin arm64), Node v24.22.1.
Install shape: launchd background service plus the T3 Code (Nightly) desktop app on the same T3 home (~/.t3).

Evidence

logs/server-child.log:

2026-10-31T01:21:06.939Z desktop-backend-child START pid=3596 port=3774
ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped. server-owner.sqlite is the ownership lock; do not delete it while a server is running.
2026-10-31T01:21:07.181Z desktop-backend-child END pid=3596 code=78

logs/boot-service.log (Oct 22):

[08:38:22.870] ERROR (#2): ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. ...
[service-launcher] Another T3 Code server owns this T3 home. Stop it, then restart this service.

userdata/server-runtime.json after reboot: "serviceManaged":true,"serverVersion":"0.1.2-nightly.20261022.3512".

Related: #26144 (Nightly conflicts with the background service after restart), #23843, #22983.

Investigated with t3 triage by Claude Code (Claude Opus 5.5).

Another confirmation of the current-service case (ServerAlreadyRunningError), this time on stable releases. It still happens on v0.1.6.

Setup

macOS 27.2 (Darwin 27.2.0), arm64
Desktop: T3 Code (Beta) 0.1.5
Background service: launchd com.t3tools.t3code.service, running runtime/versions/0.1.6/t3 __service-launcher. /.well-known/t3/environment on 3773 reports serverVersion: 0.1.6.
desktop-settings.json had no localEnvironmentEnabled, so it defaulted to true. tailscaleServeEnabled: true.

What happened
The service owned ~/.t3/userdata on 3773. Each desktop launch started its own backend on 3774, which exited with code 78. The app then showed the "another T3 Code server... or an older background service" dialog, which recommends t3 update and a service reinstall. The service was already on the latest release, so neither would have helped.

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

2026-10-31T13:56:05Z backend child pid=18124 port=3774
ERROR ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. ... code=78
(same at 13:56:27, 13:58:27, 14:00:27)

The same error also appeared on 2026-10-21, right after an OlderBootServiceError at 03:44, which matches the update-path sequence reported above.

Upstream state: #26547 (desktop reuses a running local server) was closed without merging, and DesktopBackendPool.ts has had no fix for this since #19715. Updating the desktop to 0.1.6 would not change anything.

Workaround applied: quit the app, set "localEnvironmentEnabled": false in desktop-settings.json, reopened it. No further code-78 exits. Pairing with the service via t3 pair restored existing projects and threads.

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

this also happenned to me today. after the t3 service crashlooped my mac all night and i couldn't login in the morning

The logs show loginwindow got "login items changed" notifications in pairs about every 5 seconds for two hours before the restart, meaning something kept re-registering a login item. I'm now tracking down what triggered it and whether it's still going on.

  Ran 1 shell command

The churn began around 1 a.m. at about 1,700 changes an hour and is still running after the restart, with 170 in the first few minutes. I'm going to identify the source from a single cycle of the BTM daemon's log.

  Ran 1 shell command

A background launchd job starts, exits with status 1 about half a second later, and is relaunched roughly 5 seconds after that, with each exit making macOS re-verify all login items. I'll identify the job next by checking the ~/.hogwatch/metrics path in the same log.

  Ran 2 shell commands

Found it: com.t3tools.t3code.service has run 14 times since boot (about 2 minutes ago) and exits with code 1 every time. I'll check what it is and why it fails.

  Ran 2 shell commands

I found the cause. It's an app called T3 Code on the mini whose background service is stuck in a crash loop.

What's happening:
- com.t3tools.t3code.service is set to restart whenever it dies (KeepAlive, 5-second throttle).
- Every time it starts, it crashes about half a second later while reading its own database: one stored chat message has a role that isn't user, assistant or system, and T3 Code 0.0.42 can't decode it. Its relay tunnel also gets "Unauthorized: Tunnel not found", but that isn't what kills it.
- So it restarts about every 5.5 seconds, nonstop. Its log has 133,000 "Active child exited unexpectedly" entries, so this has been going on for days. The restart survived your reboot: 15 runs in the first two minutes.

How that likely froze your login: every crash and restart makes macOS re-verify all your login and background items (the Karabiner daemons, signature checks and the rest) and notifies loginwindow. That was about 1,700 times an hour, all night. Login is the moment loginwindow has to set up your background items, so it was competing with this flood the whole time.

it would be really to make the desktop app play nicely with the service running at the same time as it did previously :)

Same thing happens with the Windows desktop app's WSL backend, not only the Local environment.

Setup: Windows desktop app, Nightly 0.1.7-nightly.20261102.4066, with the WSL backend turned on (distro: Ubuntu). A current systemd user service (t3code.service, 0.1.6-nightly.20261030.3917 at the time) was already running in the same distro on the default T3 home ~/.t3, port 3773, with T3 Connect up.

What the user saw in the WSL backend settings:

WSL backend couldn't start: Another T3 Code server is using this distro's T3 home, or an older background service is set up for it. Stop that server or pair with it, or try `t3 update` in the distro. If the older launcher cannot update, run `t3 service uninstall` and optionally reinstall with `t3 service install` from a current CLI in the distro. ...

Cause: the cause is case 2 from this issue. From server-child-wsl_Ubuntu.log:

2026-11-02T07:25:45 ERROR ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. ... pid=23164 code=78

As with the Local environment, the WSL message combines the old-service and current-service cases. It leads with update/uninstall advice that can't help when the service is current. It doesn't say that the supported setup is to turn off the WSL backend and pair with the service, which is reachable from Windows at http://127.0.0.1:3773 through WSL2 localhost forwarding.

Workaround: updated the service (t3 update --yes) so it matches the desktop, turned off the WSL backend in desktop settings, and paired the desktop with the service using t3 pair.

Possibly unrelated: a few minutes earlier, the same backend crashed with Cannot find module '@yuuang/ffi-rs-linux-x64-gnu'. That came from an older server tree, <windows-home>\.t3\userdata\wsl-server-tree\0.1.6-nightly.20261030.3917, loaded through /mnt/c.

Suggested direction: the fix proposed here (separate text per cause, and offering to switch off the local backend and pair) should cover the WSL backend path too.

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

Still reproduces on Linux with the desktop app and service on the newest nightly, 0.1.7-nightly.20261102.4080. This setup also shows the reboot ownership flip.

Setup

Omarchy (Arch) Linux x64. Desktop: AppImage, nightly.
systemd user service t3code.service on the default T3 home ~/.t3, running 0.1.7-nightly.20261102.4080, with T3 Connect enabled.
desktop-settings.json had no localEnvironmentEnabled, so it defaulted to true.

Sequence

Oct 31: an agent session installed the service while the desktop app owned the T3 home. The launcher logged [service-launcher] Another T3 Code server owns this T3 home and stayed idle for two days. Nothing in the desktop UI showed that.
Nov 2: after a reboot, systemd started the service first. It took ~/.t3/userdata on 3773 and connected T3 Connect.
Every desktop launch then started a backend on 3774, which exited with ServerAlreadyRunningError (code 78) and showed "This T3 home is unavailable".
Running t3 update, as the dialog suggests, rewrote the unit and restarted the service on the same version. The dialog came back.

So a user who installs the service so remote clients can reach the machine after a reboot can't open the desktop app after the first reboot. The dialog never mentions Local environment.

Workaround applied: set "localEnvironmentEnabled": false in desktop-settings.json with the app closed, then paired the desktop app with the service on 127.0.0.1:3773.

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

Still reproduces on macOS 27.2 (arm64) with T3 Code (Nightly) 0.1.8-nightly.20261104.4165. Case 2 (ServerAlreadyRunningError, exit 78) on every launch, with the service at stable 0.1.7 and again after matching it to the nightly with ~/.t3/bin/t3 service install. Version does not matter, as expected for case 2.

Three data points I did not see in this thread:

How the service got there. npx t3 connect / npx t3 pair on 2026-10-29 installed the service (0.1.5) while the desktop app owned ~/.t3. It crash-looped under launchd KeepAlive for a week with the same ServerAlreadyRunningError in boot-service.log (first line 21:10:50 ... ~/.t3/runtime/versions/0.1.5/t3), and the app kept working. On 2026-11-04 a nightly update was interrupted by a network problem and I rebooted. The Mac booted at 01:49, launchd started the service at login and it was listening on 3773 by 01:52, and the app's first launch at 01:55 lost the lock. Every launch since failed. This is the reboot ownership flip mentioned above: while the app runs it holds the lock, and a reboot hands it to the login service. Installing the service while the desktop app owns the home is accepted silently, which sets up the flip later.

t3 doctor --dry-run reports "Nothing to repair" in exactly this state. It would be the natural place to notice "service installed and desktop app on the same home" and offer to remove one or switch Local environment off.

The bundled CLI is not on PATH. The app writes ~/.t3/bin/t3, but t3 is "command not found" in a normal shell, so the dialog's npx t3@latest is what a user actually runs, and that resolves to the stable release.

Log, every launch:

backend child process failure output start ... port=3774
ERROR (#2): ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. ...
at acquireServerOwnership (Nightly)
at server.runServerCommand (.../apps/server/dist/binCli-UjmdhRCI.mjs:11017:16)
backend child process failure output end ... code=78

Fix that worked for me, since I only need the desktop app and use T3 Connect from Settings > Sharing & access: ~/.t3/bin/t3 service uninstall, relaunch. +1 to showing different text per cause and offering "turn off Local environment and continue" in the dialog.

Another case on Linux, this time reached from inside the app: turning Local environment back on while a current background service is running locks the desktop app out until the settings file is edited by hand.

Environment: Omarchy (Arch-based), Linux x64. Desktop app 0.1.6 (t3code-bin from pacman), background service 0.1.7 via systemd user unit, same T3 home.

What happened

Local environment was off, and the desktop app was paired with the service and working.
Switched Settings → Environments → Local environment on. The app accepted the change and relaunched.
The app's backend failed one second later, and the error dialog appeared (the app quits when it's dismissed):

05:20:09 relaunch requested: desktop:set-local-environment-enabled
05:20:10 ERROR ServerAlreadyRunningError: A T3 Code server already owns <T3 home>/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped.
05:20:10 code=78

The setting had been saved as on, and the switch can't be reached from the dialog. I didn't relaunch to confirm, but from the code each later launch should hit the same error while the service is running.

The ownership lock did its job: the service kept running with no restarts, and the 0.1.6 backend exited before running against the service's newer database (migration 79).

Recovery: with the app closed, set "localEnvironmentEnabled": false in <T3 home>/userdata/desktop-settings.json. The app then reopened normally and reconnected to the service.

Same root conflict at boot: earlier that day, the enabled service started at boot on 0.1.3 with Local environment on, and the desktop app failed with the same error at startup. The service stopped about 27 seconds later, and the desktop server took over. What stopped the service was not established.

Suggestion, in addition to the dialog changes above: check for a running service that owns this home before saving the setting, and explain the conflict instead of relaunching. If the conflict is only found at launch, offer to turn Local environment off from the dialog, so recovery doesn't need a file edit.

Drafted by Claude Code (Claude Opus 5.5) during a t3 triage session.

Confirmed on Linux with a current systemd user service (ServerAlreadyRunningError, code 78)

What happened
The desktop app (AppImage) would not start. Its backend child exited with code 78 and ServerAlreadyRunningError, because a t3 serve systemd user service already held the lock on ~/.t3/userdata. I found the cause only by reading server-child.log. The app showed no explanation I could use, and the error text offers no way to attach to the running service.

Evidence (logs/server-child.log, home path redacted; the error repeats on 9 launches, 8 on Nov 3 and 1 on Nov 4)

ERROR (#2): ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped. server-owner.sqlite is the ownership lock; do not delete it while a server is running.
phase=END details="pid=5823 code=78"   (child launched with port=3774)

Service state at the time: t3code.service active and enabled, running ~/.t3/runtime/versions/0.1.6/t3 serve on 127.0.0.1:3773. Its /.well-known/t3/environment reported serverVersion: 0.1.6.

Resolution
systemctl --user stop t3code.service made the desktop app start.

Gaps still open

The service stays enabled, so the conflict returns at the next login. Whichever of the service or the app starts first wins.
I found no supported way to point the desktop app at a running local service. The only option I found is a separate T3 home for the service.
boot-service.log shows the same error in reverse. On Nov 3, a service on 0.1.7-nightly.20261102.4093 failed because something else already held the lock.

Environment
Ubuntu, Linux x64 (kernel 7.0.0-42), Node v24.22.1. Desktop app: AppImage, version unknown. desktop-last-started-version says 0.1.6, and a 0.1.8-nightly runtime also exists on disk. Service: systemd user unit, 0.1.6 (nightly 0.1.7 earlier). Triage CLI 0.1.6, not involved.

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

Confirmed on 0.1.7 for both the CLI background service and T3 Code (Beta) desktop, on macOS 27.2 arm64, on November 7.

I had installed T3 through the CLI and run t3 connect, then downloaded the regular desktop app. The desktop just refused to open. The 89-word error dialog mixed the running-server case with old-service/update/reinstall advice, but provided no button that actually performed recovery. I couldn't tell what to do without assistance.

Evidence and recovery

The running launchd service reported installed · t3@0.1.7; the downloaded desktop's version/build was also 0.1.7.
Two backend failures at 18:34:55Z and 18:35:35Z attempted port 3774 and recorded ServerAlreadyRunningError, exit 78. This was a live same-version service, rather than the older-service error.
Removing the startup service with t3 service uninstall --base-dir "$HOME/.t3" and reopening the desktop worked. The existing project and conversation were visible; the desktop-owned 0.1.7 backend started on 3773. Remote-client reconnection was not tested.

Detailed sanitized investigation: https://gist.github.com/gkoreli/1e43e945513b43d7ffa30333e6626c7d

The Gist includes selected local evidence, pinned release/current-main source links, related issue and PR decisions, recovery limits, and proposed acceptance criteria. The inspected current-main ownership handler is unchanged: show the combined error box, then quit.

t3 connect and the desktop are native capabilities. I expect them to converge predictably on one usable server and desktop, with repeat opens/setup preserving that state. The minimum recovery needs to be an actual button—e.g. Use running server or Use desktop instead—that carries out the selected transition, explains its effect on running work/remote access, and keeps Settings reachable. A paragraph of terminal commands isn't that recovery flow.

I understand #20250's response classified automatic attachment as a feature; #8114 already covers that broader proposal. The immediate recovery-button/Settings-access gap belongs here even if automatic attachment is scoped separately. The one-owner protection should remain.

Investigated and drafted with Codex from local evidence and upstream source. Credentials, pairing links, private project/chat names, and full logs are omitted.

Note

🤖 Claude Opus 5.5 responding on behalf of Braden

Confirmed on Linux with the desktop and service both on 0.1.8-nightly.20261107.4327 (Omarchy 4.5, AppImage, t3code.service on ~/.t3). onStateDirOwned on main (25bf84a) is unchanged.

One point on the wording. The dialog's final suggestion, "set a separate T3CODE_HOME and pair with the running server", leaves the desktop's own local environment running in the new home. The machine then appears twice in the picker under the same hostname label, with two environment IDs and no way to rename either on desktop. It also defeats the shared-home environment-id check in #31358 and #21661. Following it here gave two malta entries. #30333 replaces that advice with turning off Local environment in the same home, which avoids both problems.

Confirmed on stable 0.1.7 for both the desktop AppImage and the systemd service on Ubuntu, with T3 Connect on. The conflict happens in both startup orders.

Setup

Ubuntu, Linux x64 (kernel 7.0.0-43-generic), Node v24.22.1
Desktop: AppImage 0.1.7 (stable)
Background service: systemd user unit t3code.service installed by t3 up (t3 0.1.7), T3CODE_HOME=~/.t3, listening on 127.0.0.1:3773 with the T3 Connect managed tunnel. /.well-known/t3/environment reports serverVersion: 0.1.7.
desktop-settings.json had no localEnvironmentEnabled, so it defaulted to true.
t3 doctor reported no problem.

What happened

Nov 6: the desktop app started first and owned ~/.t3/userdata. The service then failed with ServerAlreadyRunningError on line 1 of boot-service.log, followed by [service-launcher] Another T3 Code server owns this T3 home. Stop it, then restart this service.

Nov 8: the service started at login (12:32) and owned the home. Each desktop launch (11:34, 11:39 and 11:40 UTC) started a backend on port 3774, which exited with code=78:

ServerAlreadyRunningError: A T3 Code server already owns ~/.t3/userdata. Stop that server, or use a separate T3 home and pair with it, then retry. No server was stopped.
    at acquireServerOwnership (.../apps/server/dist/server-UENsecr6.mjs:44483:27)

The app then showed "This T3 home is unavailable".

After that dialog, the app from the 11:40 launch kept running with no window and ignored SIGTERM. Only SIGKILL stopped it (Desktop app stays running windowless after the "T3 home is unavailable" dialog and ignores Quit and SIGTERM #23843).

Expected: the desktop app detects the running service on the same home and attaches to it, instead of starting its own backend. At v0.1.7 (322f6544) the desktop never reads server-runtime.json or probes for an existing server. DesktopBackendManager routes exit code 78 to onStateDirOwned and quits.

Workaround applied: killed the leftover app, set "localEnvironmentEnabled": false in desktop-settings.json, then paired the app with the service on http://127.0.0.1:3773 (t3 pair from the service's 0.1.7 runtime). The app opened without the dialog, and the existing threads came back.

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

Navigation Menu

Repository navigation

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

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

What happened

Environment

Evidence and diagnosis

Verified recovery

What happened

Diagnosis (source at `v0.1.6-nightly.20261030.3940`)

Workaround that worked

Environment

Evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What happened

Diagnosis

Steps to reproduce

Version

Environment

Evidence

Related issues

Fix applied or workaround

Filed by

Activity

leo-mathurin commented on Oct 21, 2026

sintypitch commented on Oct 21, 2026

ruxir-ig commented on Oct 22, 2026

kestereverts commented on Oct 22, 2026

mikeohuo commented on Oct 23, 2026

AndySakov commented on Oct 23, 2026

w00dy1981 commented on Oct 24, 2026

tzachbon commented on Oct 25, 2026

tzachbon commented on Oct 25, 2026

eddietex commented on Oct 29, 2026

eddietex commented on Oct 29, 2026

yalcincanulus commented on Oct 30, 2026

What happened

Environment

Evidence and diagnosis

Verified recovery

AojdevStudio commented on Oct 31, 2026

What happened

Diagnosis (source at v0.1.6-nightly.20261030.3940)

Workaround that worked

Environment

Evidence

MaxiAschenbrenner commented on Oct 31, 2026

bazo commented on Nov 1, 2026

bograh commented on Nov 2, 2026

Gdsimms commented on Nov 2, 2026

alext8900 commented on Nov 4, 2026

carloschida commented on Nov 4, 2026

slimabbadi commented on Nov 4, 2026

gkoreli commented on Nov 7, 2026

bradenbiz commented on Nov 7, 2026

miklosme commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Diagnosis (source at `v0.1.6-nightly.20261030.3940`)