Muse provider always Unavailable on Windows: Muse starts ~4s slower inside a job object and the version probe allows 4s#24165
What happened
On my Windows PC, the Muse Code provider in T3 Code shows Unavailable · Muse Code CLI version check timed out. on every refresh, so I can't use Muse at all. It worked a couple of days earlier. Muse runs fine from a terminal.
Diagnosis
checkMuseProviderStatus (packages/provider-muse/src/server/status.ts) runs muse --version under Effect.timeoutOption(DEFAULT_TIMEOUT_MS), and DEFAULT_TIMEOUT_MS is 4_000 (packages/provider-core/src/server/snapshotProbe.ts). This is unchanged on current main.
On this machine Muse takes ~4.2–4.7 s to answer --version when started by the T3 server, so every probe is interrupted just past the budget. The cause of the slowness: Muse starts ~4 s slower whenever it runs inside a Windows job object, and the T3 server process runs inside one. Children inherit the job.
muse-bin-1.4.12-R6909.1.exe --version, same machine:
| Launch context | In a job object? | Wall time |
|---|---|---|
PowerShell / cmd / Node spawn with pipes | yes | 3.6–4.3 s |
| T3 server probe (from trace log) | yes | >4.2 s (interrupted) |
Created via WMI Win32_Process.Create | no | 0.05–0.06 s |
| Launched through Git Bash (MSYS creates children outside the job) | no | 0.03–0.06 s |
The stall isn't specific to one Muse release. Official Windows builds were verified against their manifest SHA-256 and timed inside a job object:
| Muse build | --version inside a job |
|---|---|
| 1.4.11-R6667.1 | 5.2–8.7 s |
| 1.4.12-R6909.1 (muse-stable) | 4.3–4.7 s |
| 1.4.13-R6996.1 (muse-canary) | 5.3–7.1 s |
Ruled out inside the job, each with no effect: stdio (pipe/inherit/ignore), detached: true (no console), cwd, a minimal environment, the full environment from the fast context, PATH, the parent executable's name, and antivirus. --help pays the same penalty. CPU time stays around 0.05 s for the whole run, so Muse is idle-waiting rather than working, and there are no child processes or network connections during the wait. The stall itself is likely Muse-side, but T3's 4 s probe budget turns it into a hard Unavailable.
Raising the timeout fixes it. As a local test I raised only this probe's timeout to 15 s in the installed server bundle. After a restart the version probe completed in 5.9 s, model discovery succeeded, and Muse works normally in T3.
Suggested fix, mirroring #16544 for OpenCode: give the Muse version probe a realistic budget (the model-catalog probe right after it already allows 12 s) and/or keep an already-ready Muse snapshot through a single slow probe. Alternatively, spawn provider probes with CREATE_BREAKAWAY_FROM_JOB where the job permits it.
Steps to reproduce
- On Windows 11, install Muse Code with the official installer (
%LOCALAPPDATA%\Programs\muse\muse.cmd). - Launch the T3 Code desktop app (Nightly) and enable the Muse Code provider.
- Open Settings → Providers, or refresh provider status. The status is Unavailable with "Muse Code CLI version check timed out."
- Optional confirmation: from any shell inside a job object (for example PowerShell), time
muse-bin-<version>.exe --version. It takes ~4 s. Launched outside a job (for example viaInvoke-CimMethod Win32_Process Create), it returns in ~0.05 s.
Version
T3 Code desktop 0.1.3-nightly.20261023.3579
Environment
Windows 11, T3 Code desktop app (Nightly) with local server, Muse Code 1.4.12 (1.4.12-R6909.1) via the official Windows launcher
Evidence
| 1 | # Settings → Providers |
| 2 | Unavailable · Muse Code CLI version check timed out. |
| 3 | |
| 4 | # server.trace.ndjson, before the local timeout change (every probe looks like this) |
| 5 | {"name":"snapshotProbe.spawnAndCollect","durationMs":4249.2017,"exit":{"_tag":"Interrupted","cause":"InterruptError: All fibers interrupted without error ..."}} |
| 6 | {"name":"checkMuseProviderStatus","durationMs":4274.4562,"exit":{"_tag":"Success"}} |
| 7 | |
| 8 | # after raising only the Muse version probe timeout to 15 s |
| 9 | {"name":"snapshotProbe.spawnAndCollect","durationMs":5879,"exit":{"_tag":"Success"}} |
| 10 | {"name":"discoverMuseModels","durationMs":2662,"exit":{"_tag":"Success"}} |
Related issues
- #11080: the same failure mode for OpenCode (hardcoded 4 s
--versionprobe → Unavailable), fixed for OpenCode only by #16544. #12973 (4 s too tight on Windows) and #13326 were closed as its duplicates. Muse still uses the shared 4 sDEFAULT_TIMEOUT_MS. - #7230: timed-out probes cached as errors (fixed).
Investigated and drafted by Claude Opus 5.5 (Claude Code agent running in T3 Code).