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:

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:

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

1. On Windows 11, install Muse Code with the official installer (%LOCALAPPDATA%\Programs\muse\muse.cmd).
2. Launch the T3 Code desktop app (Nightly) and enable the Muse Code provider.
3. Open Settings → Providers, or refresh provider status. The status is Unavailable with "Muse Code CLI version check timed out."
4. 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 via Invoke-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

# Settings → Providers
Unavailable · Muse Code CLI version check timed out.

# server.trace.ndjson, before the local timeout change (every probe looks like this)
{"name":"snapshotProbe.spawnAndCollect","durationMs":4249.2017,"exit":{"_tag":"Interrupted","cause":"InterruptError: All fibers interrupted without error ..."}}
{"name":"checkMuseProviderStatus","durationMs":4274.4562,"exit":{"_tag":"Success"}}

# after raising only the Muse version probe timeout to 15 s
{"name":"snapshotProbe.spawnAndCollect","durationMs":5879,"exit":{"_tag":"Success"}}
{"name":"discoverMuseModels","durationMs":2662,"exit":{"_tag":"Success"}}

Related issues

• [Bug]: OpenCode provider flagged Unavailable when CLI version probe exceeds hardcoded 4s #11080: the same failure mode for OpenCode (hardcoded 4 s --version probe → Unavailable), fixed for OpenCode only by fix(server): slow OpenCode wrappers no longer show as unavailable #16544. [Bug]: OpenCode marked unavailable on first launch after reboot: 4 s version probe is too tight on Windows #12973 (4 s too tight on Windows) and Provider status checks fail on weaker machines #13326 were closed as its duplicates. Muse still uses the shared 4 s DEFAULT_TIMEOUT_MS.
• [Bug]: A timed-out provider status probe is cached as an error, so the provider stays unavailable for new sessions #7230: timed-out probes cached as errors (fixed).

Investigated and drafted by Claude Opus 5.5 (Claude Code agent running in T3 Code).