[Bug]: Disabling the WSL backend in a running desktop does not stop it; supervisor respawns it on exit

[PrinceJunkie]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Windows desktop app with the WSL backend enabled and running (desktop.backendInstance.start {"id":"wsl:Ubuntu"} in desktop.trace.ndjson).
2. In settings, disable the WSL backend. The trace logs desktop.settings.writeSettings, desktop.wslBackend.reconcile with event tearing down WSL backend, desktop.ipc.wsl.setEnabled.
3. Inside WSL: pgrep -fa wsl-runtime. The ~/.t3/wsl-runtime/sha256-…/t3 --bootstrap-fd 0 process is still running and still listening.
4. Kill that process inside WSL.

Expected behavior

Step 2 stops the WSL runtime process and unregisters the instance from the backend pool. Nothing respawns it while the setting is off.

Actual behavior

The process survives the teardown (checked 90 seconds later). When it is killed, the pool supervisor restarts it:

desktop.backendInstance.scheduleRestartFiber  "backend exited unexpectedly; restart scheduled"
desktop.backendInstance.start {"id":"wsl:Ubuntu"}

This happened twice in a row (00:19:12 and 00:20:25). The setting itself persisted (desktop-settings.json no longer contains wslBackendEnabled), and a full app restart does not start the WSL backend, so only the live reconcile path is affected.

Side effect: the respawned WSL runtime shares ~/.t3/userdata with a t3 service install server in the same distro, and each one re-registers its own port with the relay on startup (last writer wins), which repeatedly broke T3 Connect for the Linux environment.

Impact

Degrades the experience (needs a full app restart to actually disable WSL; breaks remote access when combined with a WSL service).

Version or commit

Desktop 0.0.42 (Windows).

Environment

Windows 11, WSL2 Ubuntu (networkingMode=mirrored), t3 service install inside the same distro.

Logs or stack traces

00:17:14 desktop.settings.writeSettings
00:17:14 desktop.wslBackend.reconcile  ["tearing down WSL backend"]
00:17:14 desktop.ipc.wsl.setEnabled
00:19:12 desktop.backendInstance.scheduleRestartFiber ["backend exited unexpectedly; restart scheduled"]
00:19:12 desktop.backendInstance.start {"id": "wsl:Ubuntu"}
00:20:25 desktop.backendInstance.scheduleRestartFiber ["backend exited unexpectedly; restart scheduled"]
00:20:26 desktop.backendInstance.start {"id": "wsl:Ubuntu"}

Workaround

Restart the desktop app after disabling the WSL backend.

[juliusmarminge]

Triage

Confirmed as a real desktop bug in the live WSL disable path. Settings persist correctly; a full app restart correctly stays off. Only the running-app reconcile/unregister path fails, and the pool supervisor can then respawn wsl:<distro>.

What the traces show

The reported sequence matches the dual-mode disable path:

1. desktop.ipc.wsl.setEnabled(false) persists via applyWslWindowsFallback (wslBackendEnabled omitted from desktop-settings.json).
2. desktop.wslBackend.reconcile logs tearing down WSL backend and calls pool.unregister("wsl:Ubuntu").
3. The Linux ~/.t3/wsl-runtime/…/t3 --bootstrap-fd 0 process is still running afterward.
4. When that process is killed, desktop.backendInstance.scheduleRestartFiber (backend exited unexpectedly; restart scheduled) followed by desktop.backendInstance.start { id: "wsl:Ubuntu" }.

scheduleRestart only fires when desiredRunning is still true. So teardown logged a stop but left the instance supervisor running.

wsl-only disable and “disable local environment” already relaunch the app. Dual-mode WSL off is the path that tries a live unregister.

Likely cause

DesktopBackendPool.register is supposed to fork a child scope per instance so unregister can close it and run DesktopBackendManager.stop() (sets desiredRunning = false, interrupts the restart fiber, SIGTERMs the child).

In apps/desktop/src/backend/DesktopBackendPool.ts, register captures Effect.context<BackendInstanceFactoryRequirements>(). At runtime that is the entire fiber context, including the pool layer Scope. It then does:

makeBackendInstance(spec).pipe(
  Effect.provide(factoryContext),
  Scope.provide(instanceScope),
)

Inner Effect.provide(factoryContext) overwrites the outer Scope.provide(instanceScope). Instance finalizers and restart fibers attach to the pool layer scope. unregister closes an empty forked scope, drops the id from the registry, and returns immediately (same-second IPC completion). The supervisor stays alive; killing the Linux process looks like a crash and gets restarted.

The file comment already says the child scope should own finalizers; the provide order plus full-context capture defeats that. There is no test that register + start + unregister actually stops the process or prevents a restart.

Secondary risk after that fix: the child is wsl.exe, and SIGTERM on the Windows relay may not kill the Linux t3 process. Worth verifying; if it survives, add an in-distro kill. The respawn itself is explained by the supervisor never stopping.

Connect / t3 service side effect

The WSL backend and t3 service install in the same distro both use ~/.t3/userdata. Each register their port with the relay on startup (last writer wins). A ghost supervisor that keeps restarting the desktop WSL runtime will keep stealing Connect from the service. Related class of problem: #9652.

Suggested fix

1. Make instanceScope actually own makeBackendInstance (pick a context that does not include Scope, and/or provide instanceScope so it wins).
2. Optionally call instance.stop() before unregister so teardown does not depend only on scope close.
3. Test: after unregister, the child is gone, desiredRunning is false, and an exit does not scheduleRestart / start.
4. Confirm the Linux t3 process dies; if not, kill it inside the distro.

Workaround remains: restart the desktop app after disabling the WSL backend.

Related

• Desktop: parallel WSL + Windows backends with mode picker #2751 — parallel WSL backends and this register/unregister wiring
• feat(desktop): allow disabling the local environment #9194 — local-environment disable relaunches instead of live teardown
• feat(desktop): run the WSL backend from the Linux CLI archive #11511 — packaged WSL runtime under ~/.t3/wsl-runtime
• fix(server): prevent duplicate servers for one state directory #9652 — two servers sharing one state directory