Feature: Support running T3 Code as a Windows background service #24429

I ran into this on Windows with T3 Code 0.1.3: the linked environment becomes reachable when I run t3 serve, but linking T3 Connect alone does not keep the host running or start it at sign-in.

The installed CLI reports:

T3 Code service
  Status: unavailable on this machine
  Supported on: Linux with systemd, macOS with launchd

Current main (5211acfe95a0c6d82a60e2524b5e46b47fe67a3e) still has that platform boundary. On Windows, the desktop app also quits when its last window closes. A Windows Startup shortcut can launch the desktop app at sign-in, but that is not a supervised, desktop-independent host.

I found the earlier Windows implementation in #5848, which was closed unmerged, and the separate tray/lifetime question in #10161. I am adding the report here rather than opening a competing feature request.

Would maintainers approve a first-party, opt-in Windows logon host in the existing t3 service lifecycle, or prefer a desktop startup option? The behavior I need is to reconnect through T3 Connect after sign-in without manually running serve, using the same Windows user and existing environment, with a clear way to inspect and disable it. Any independent host also needs to respect single-server ownership, graceful shutdown, and update/uninstall behavior.

I can help implement and test the agreed scope on Windows. I have not implemented Windows service support; the accompanying documentation correction only explains today's supported behavior.

Prepared with GPT-6 via Codex.

+1. Another Windows 11 user who wants to run T3 Code headless and reach it only from a browser over Tailscale or from the mac/iOS apps, without keeping the desktop window open.

What happens on 0.1.4 today

• t3 service status reports unavailable on this machine. It only supports systemd and launchd.
• The desktop app can't attach to a server that's already running on the same T3 home. If t3 serve holds userdata/server-owner.sqlite, the app shows "This T3 home is unavailable" and quits. So on Windows it's the desktop app or a background server, never both.
• Every release already ships a standalone t3-<v>-win32-x64.zip, and its t3.exe runs t3 serve fine on Windows. That's what this setup runs, from runtime/versions/<v>/t3.exe, the same layout t3 update uses. So the runtime is there; the missing piece is the boot-service layer.

Current workaround (works, but everything is hand-built)

• A Task Scheduler task that runs as the user (Interactive logon, at sign-in; the account has no password, so it can't use "run whether logged on or not"). It runs conhost.exe --headless cmd /c t3-server.cmd serve --base-dir %USERPROFILE%\.t3 --host 127.0.0.1 --port 3773 --tailscale-serve >> serve.log 2>&1, with restart-on-failure every minute. Without conhost --headless, an Interactive task leaves a console window open on the desktop.
• A PowerShell updater that stands in for t3 update plus t3 service restart. It resolves the release, checks the zip against SHA256SUMS, extracts it to runtime/versions/<v>, checks t3.exe --version, repoints a .cmd shim, kills the server pid from server-runtime.json, restarts the task and prunes old versions.
• Rough edges: with a plain cmd.exe action, closing the console window killed the wrapper (0xC000013A). Task Scheduler then showed "Ready" while the server kept running, orphaned. With conhost --headless the task stays "Running" over conhost → cmd → t3.exe, but stopping still goes by the pid in server-runtime.json, since there's no graceful stop. t3 update doesn't know about the task.

This and other logon-based approaches (the Startup folder, win-t3service) only work once someone signs in. A machine that reboots and sits at the lock screen stays offline. Starting at boot needs either a stored password or S4U, and S4U loses access to DPAPI and Credential Manager. A first-party design would have to pick a trade-off here.

On #5848

That PR was closed by an automated triage pass. The stated reason was that it "adds a Windows background service even though current tests explicitly reject that platform." Those tests encode the current scope ("unsupported"). As far as I can tell, they don't record a decision that Windows should never be supported, so the closure looks unintentional rather than a rejection of the feature. Could a maintainer take another look, or say what a first-party Windows design should look like? For example:

• Task Scheduler at boot vs. at logon, or a real Windows service (SCM) with a password or S4U.
• A graceful stop path, since Windows has no SIGTERM. The review bot's two-servers-on-one-DB race concerns on feat(server): t3 service runs T3 Code in the background on Windows #5848 are a good checklist here.
• t3 update and t3 service restart integration, mirroring the systemd/launchd flow.

I'm happy to test a branch on Windows 11, or help revive #5848 or work on a new PR if a maintainer is open to it.

I also need the opt-in Windows logon host proposed here, with support for both t3 update and updates requested through a connected client. Two details from my setup:

The host needs access to the signed-in desktop. I previously used a stored-password boot task. It ran in session 0, where GUI apps launched by agents had no visible desktop. Switching to an interactive logon task fixed that. A host that requires me to remain signed in is sufficient for this use case; a conventional Windows service running in session 0 would not cover it.

The built-in server updater needs to manage this host. My current workaround is a hidden Task Scheduler logon task running npx --yes t3@nightly serve in a loop. My t3up helper force-stops the process listening on the configured server port; the loop invokes t3@nightly again after 10 seconds. The helper only checks that a new process is listening, so it bypasses T3's managed update lifecycle and does not verify the resulting version.

In current main's server updater, an unmanaged t3 serve host is refused with: "Remote updates require the T3 Code background service. Run t3 service install on the server machine." That is the gap I want a supported Windows host to close, including a coordinated shutdown and restart instead of the port-based force-kill.

I can test the agreed design against this interactive desktop workflow and updates from another client.

Same need here: Windows Server dev VM reached through T3 Connect. A headless t3 serve in a logon scheduled task works, but it can't self-update (no serverSelfUpdate capability), so we went back to keeping the desktop app open. A first-party Windows service that supports updates requested from a connected client would cover this.

Could a maintainer approve or reject this scope for Windows support in t3 service? I'd send it as small PRs, in order:

1. Windows backend for t3 service install, status, restart, uninstall. A per-user Task Scheduler task that runs at logon in the user's interactive session. It stores no password and doesn't run in session 0: a session-0 host gives agent-launched GUI apps no visible desktop, and git and gh lose their Credential Manager logins. The task restarts the server after a crash and writes the same logs the systemd and launchd backends do.
2. Updates for that host. t3 update and updates requested from a connected client hand off to the task, so the updater outlives the server it restarts. This is what the comments above ask for: a headless t3 serve today has no serverSelfUpdate.
3. Docs. docs/user/background-service.md drops "Windows unsupported".

Out of scope: a conventional Windows Service (SCM), start before sign-in, and any change to the Linux or macOS backends.

Background:

• feat(cli): t3 service runs on Windows, so updates can manage a Windows host #27415 implemented 1 and 2 together (+702/-58) and was closed for lacking this approval. Macroscope's two High findings there, a disabled task left stopped after a repair and an install that can overwrite a pending remote update, would be fixed in the split PRs.
• Users run their own workarounds now, such as win-t3service, which uses the same logon-task approach.
• [Feature]: Support Windows background services in `t3 service install` #28847 asks for the same thing. Votes could go here.

Two direction questions: is Task Scheduler the backend you want, and is this three-PR split acceptable?