[Bug]: Disabling the WSL backend in a running desktop does not stop it; supervisor respawns it on exit
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
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
- Windows desktop app with the WSL backend enabled and running (
desktop.backendInstance.start {"id":"wsl:Ubuntu"}in desktop.trace.ndjson). - In settings, disable the WSL backend. The trace logs
desktop.settings.writeSettings,desktop.wslBackend.reconcilewith eventtearing down WSL backend,desktop.ipc.wsl.setEnabled. - Inside WSL:
pgrep -fa wsl-runtime. The~/.t3/wsl-runtime/sha256-…/t3 --bootstrap-fd 0process is still running and still listening. - 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in apps/desktop by tracing desktop.wslBackend.reconcile and desktop.ipc.wsl.setEnabled, then follow desktop.backendInstance.scheduleRestartFiber and desktop.backendInstance.start. Reproduce the live disable flow with a running wsl:Ubuntu backend and inspect the trace. Done means disabling WSL stops the runtime, unregisters the instance, and prevents supervisor respawns without restarting the app.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend, desktop
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100