WSL: stale `run\wsl-daemons` record from pre-update instance blocks reconnect ("another live app instance already manages WSL distro")

[johnnyhaggs]

Short summary

After a self-update on Windows, the relaunched app refuses every WSL environment with another live app instance already manages WSL distro. The cause is the record that the previous, now-dead instance left in %USERPROFILE%\.copilot\run\wsl-daemons\. The refusal persists across app restarts until that file is removed by hand. After removal, reconnect works immediately with no restart.

Affected version or release

v1.1.26 (commit 5ab79c8), updated from v1.1.25 (6ab388f). Also hit on the v1.1.24 → v1.1.25 update.

Installation context

Windows 11 (10.0.26200), WSL 2.9.4.0 (kernel 6.18.35.2-1). Two WSL environments, Ubuntu and <custom-distro>, both Ubuntu 24.04. copilotd 0.9.0 → 0.9.2.

What happened?

Timeline (UTC) for the 1.1.25 → 1.1.26 update:

Time	Event
10-01 20:07:58	1.1.25 starts (pid 59952), connects both distros, writes run\wsl-daemons\59952-134353588756033422.json
10-01 22:08:13	Update staged, waiting for user to restart version=1.1.26
10-02 12:13:40	User confirmed staged update → Created pre-update backup. This is the last line in the 1.1.25 log. No shutdown or WSL teardown is logged, and the record is not removed.
10-02 12:14:34	1.1.26 starts (pid 40520). Both distros are refused about 100 ms later (below).
10-02 12:17:23	Manual app restart (pid 60836). Same refusal at startup and on every session resume through 13:24.
10-02 13:26:53	Stale JSON moved out of run\wsl-daemons\ (app left running)
10-02 13:27:15	Next session resume: copilotd 0.9.2 installed, wsl rehydrate complete

The stale record:

{"owner_pid":59952,"owner_executable":"...\\GitHub Copilot\\github.exe","owner_creation_time":134353588756033422,
 "daemons":[{"pid":64196,"distro":"<custom-distro>","executable":"C:\\Windows\\System32\\wsl.exe","creation_time":134353595937668693},
            {"pid":5628,"distro":"Ubuntu","executable":"C:\\Windows\\System32\\wsl.exe","creation_time":134353596493940384}]}

Errors:

WARN wsl::rehydrate: wsl rehydrate failed env_id=wsl:Ubuntu error=another live app instance already manages WSL distro `Ubuntu`
WARN wsl::rehydrate: wsl rehydrate failed env_id=wsl:<custom-distro> error=another live app instance already manages WSL distro `<custom-distro>`
WARN handlers::session: failed to resume session ... error=remote host `wsl:<custom-distro>` recovery failed: another live app instance already manages WSL distro `<custom-distro>`
WARN workspace::live_state::ahp: AHP producer: could not build host env ... error=host `wsl:<custom-distro>` is not registered or unavailable

State checked while the error was still occurring (around 13:25):

• owner_pid 59952 was not running.
• Daemon pids 64196 and 5628 were not running.
• Exactly one github.exe (60836) was running.
• No file under run\ was locked except single-instance.lock, which 60836 held.

So the "live instance" check treats a record whose owner is dead as live. The 1.1.25 instance also exited through the update-restart path without removing its record.

Second occurrence (1.1.24 → 1.1.25, 9/30): The 1.1.24 log (pid 62052) ends abruptly at the update at 00:09:52 UTC. The first 1.1.25 launch, 66 s later, logged another live app instance already manages WSL distro for the same distro. That record (62052-…json) stayed in place until it was removed by hand.

Steps to reproduce

1. On Windows, configure and connect at least one WSL environment. %USERPROFILE%\.copilot\run\wsl-daemons\<pid>-<ctime>.json now exists.
2. Let the app stage an update, then confirm the restart.
3. After relaunch, open a session on the WSL environment.
4. The connection fails, and the log shows another live app instance already manages WSL distro. Restarting the app doesn't help.
5. Move the old wsl-daemons\*.json whose owner_pid isn't running. The next session resume reconnects.

Expected behavior

• An instance that exits, including through the update-restart path, removes its wsl-daemons record after reaping its daemons.
• On startup or rehydrate, a record whose owner_pid isn't running, or whose process creation time doesn't match owner_creation_time, is treated as stale. The new instance reaps any listed daemons that are still alive, then takes ownership instead of refusing.

Additional context

• Related: App leaks its WSL copilotd on restart/update; orphaned daemons cause "refusing to authenticate ... keys differ" #3667, orphaned copilotd after restart/update, fixed in v1.1.24. This ownership record looks like part of that fix. Also Suddenly WSL connections are broken with v1.24 #4331, WSL broken since 1.24, where a maintainer noted "something is stale and being hung onto". This may be one of the stale-state causes behind Suddenly WSL connections are broken with v1.24 #4331.

• Workaround (PowerShell). It moves records whose owner isn't running. Then reopen a WSL session; no app restart is needed.

  $d = "$env:USERPROFILE\.copilot\run\wsl-daemons"
  Get-ChildItem $d -Filter *.json |
    Where-Object { -not (Get-Process -Id (Get-Content $_.FullName -Raw | ConvertFrom-Json).owner_pid -ErrorAction SilentlyContinue) } |
    Move-Item -Destination $env:TEMP

[Davsterl]

Thank you so much for this analysis! I will use it to check the recent fix I put in.

[KMathurTDY]

We hit what looks like the same root cause on v1.1.26, but the symptom was different, so here are the details in case they help.

Environment

• Windows 11 (10.0.26200), WSL 3.0.1.0 (kernel 6.18.40.1-1), single distro: Ubuntu 24.04.4
• App updated 1.1.24 → 1.1.25 (10-01), then 1.1.25 → 1.1.26 (10-05)
• copilotd 0.9.0 installed; app pins 0.9.2

Symptom (differs from the original report)

• Settings → Environments showed Ubuntu as "Connection failed — Couldn't connect to Ubuntu. Try again…"
• Clicking Connect did nothing in the backend. No log line at all was written for the attempt: no wsl::spawn, no wsl::install, no error. Restarting the app and running wsl --shutdown didn't help.
• We never saw another live app instance already manages WSL distro in any log.
• The only related errors were on startup rehydrate, then repeating:

  WARN wsl::rehydrate: wsl rehydrate failed env_id=wsl:Ubuntu error=WSL environment needs a GitHub account selection before it can reconnect
  WARN remote_host::commands: remote_host_remove_environment: remove failed env_id=wsl:Ubuntu error=no host registered with id wsl:Ubuntu
  WARN repo_config_watch: host authentication failed ... host_id=wsl:Ubuntu error=remote host `wsl:Ubuntu` recovery failed: the remote host is not currently connected
  

  The remove_environment failure came from an attempt to remove and re-add the environment. It looks like the environment was partly deregistered, while remote_environment_metadata still had the wsl:Ubuntu row.

Stale record

run\wsl-daemons\ held a single record whose owner_pid belonged to the 1.1.24 instance that exited through the 1.1.24 → 1.1.25 update restart. Its mtime matched the last copilotd spawn by that instance. Neither the owner nor the daemon wsl.exe pid was running:

{"owner_pid":<dead 1.1.24 pid>,"owner_executable":"...\\GitHub Copilot\\github.exe","owner_creation_time":...,
 "daemons":[{"pid":<dead pid>,"distro":"Ubuntu","executable":"C:\\Windows\\System32\\wsl.exe","creation_time":...}]}

run\wsl-provisioning\ also still had a leftover <hash>.lock from the same time.

That record survived two later updates (→1.1.25, →1.1.26) and several manual restarts.

Fix

Moving the stale wsl-daemons\*.json and the wsl-provisioning\*.lock out of run\ while the app was running, then clicking Connect, immediately produced copilotd missing or mismatched; installing pinned version ... version="0.9.2". So the silent Connect looks like the same stale-record check, reached through a path that doesn't log it.

Related: copilotd download hits a ~5 min cap on slow links

After that, the 0.9.2 auto-install failed exactly 5 minutes in:

07:23:31 wsl::install: copilotd missing or mismatched; installing pinned version ... version="0.9.2"
07:28:34 wsl::commands: WSL environment setup failed distro=Ubuntu error=couldn't download the verified copilotd release artifact: copilotd-0.9.2-x86_64-unknown-linux-gnu.tar.gz read failed: error decoding response body

The same thing happened with 0.9.0 earlier, and one retry did succeed in 298 s. The tarball is ~158 MB. On our link the official installer (curl -fsSL https://gh.io/copilotd-install | COPILOTD_VERSION=0.9.2 bash) needed ~11 min at ~250 KB/s, then verified the SHA-256. With the binary pre-installed, Connect worked immediately (adopted the daemon's endpoint record ... version=0.9.2).

Suggestions:

1. Treat a wsl-daemons record as stale when owner_pid and owner_creation_time don't match a running process.
2. Clean the record up on the update-restart path.
3. Log the reason when Connect is rejected early.
4. Scale or remove the copilotd download timeout, or report it as a timeout instead of error decoding response body.