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

Activity

1. juliusmarminge commented on Sep 19, 2026

   

   juliusmarminge

   on Sep 19, 2026

   Member

   More actions

   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
2. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 19, 2026
3. juliusmarminge

   closed this as completedon Oct 18, 2026