[only21mil]

Problem

On Windows, Muse Code shows Unavailable · Muse Code CLI version check timed out. on every refresh, even though muse works from a terminal (https://git.cafe/pingdotgg/t3code/issues/24165). The reporter traced it: Muse takes about 4 to 9 seconds to answer muse --version when it runs inside a Windows job object, and the processes the T3 server starts run inside one. The Muse status check gives that command the shared 4 second budget, so every check is cut off and Muse can't be used.

Change

The Muse version check now gets its own 15 second budget instead of the shared 4 second default. This follows https://git.cafe/pingdotgg/t3code/pulls/16544, which made the same change for OpenCode's version probe. The shared default and other providers stay as they are. A Muse CLI that really hangs still shows the same timeout message, now after 15 seconds instead of 4.

Scope

Bug fix (Windows only): a working provider shows as Unavailable. Fixes https://git.cafe/pingdotgg/t3code/issues/24165. The issue's suggested fix is "give the Muse version probe a realistic budget", mirroring https://git.cafe/pingdotgg/t3code/pulls/16544 for https://git.cafe/pingdotgg/t3code/issues/11080.

Verification

Windows 11 VM, T3 server from source at main (0f13d2ccbd) and at this head (11e38e53f7), fresh state, a freshly installed Muse Code 1.4.15, status read in T3's Browser panel and the server's trace file.

On this machine the first --version of a newly installed Muse binary takes about 4.1 to 4.3 s inside a job object, as the T3 server's child processes are; later runs take 0.04 s.

main: the version check is cut off and Muse shows as Unavailable.

This head: the same fresh install answers, model discovery runs, and Muse shows version 1.4.15. "Needs attention" is the missing Muse login.

The new status test fails on main and passes on this head.

Not checked:

• The stall on every check that the reporter measured. On my virtual machine only the first start of a newly installed binary was slow. After that, Muse 1.4.12 and 1.4.15 answered in 0.04 to 0.68 s inside a job object, from an SSH session and from the interactive desktop session.
• A Muse CLI that hangs forever. The timeout path itself is unchanged; it now fires at 15 seconds.
• The web, desktop and mobile clients on this head. The change is in the server's version check; the two Windows captures show its result in Settings.

Change detail, method, server traces, timing and test lines

Scope detail: This PR is that fix and nothing else. It does not keep a ready snapshot through a slow check or change any other provider. A slow Windows start no longer shows Muse as unavailable.

Tests: the new test fails on main and passes on this head, on the same machine. I ran this head first, then main with only this head's test file copied in. main fails "waits for a version check that takes several seconds to answer"; this head passes all 5.

The Muse version check now gets its own 15 second budget instead of the shared 4 second default. The budget is there to stop a hung --version. 15 seconds still does that, and it covers the slowest start the reporter measured (8.7 s on Muse 1.4.11) with room to spare. It is also the value the reporter tested on their machine. The model catalog check right after it already allows 12 seconds.

Raising a timeout can look like a timing patch over a race. Here nothing races. The command is just slow to start under a job object, and the reporter ruled out stdio, cwd, environment, PATH and antivirus. The other fix they suggested, starting probes with CREATE_BREAKAWAY_FROM_JOB, has no spawn option in Node, and a job can forbid breakaway anyway.

Method: a Windows 11 Enterprise Evaluation 10.0.26300 virtual machine. I ran the T3 server from source at main (0f13d2ccbd) and at this head (11e38e53f7), one at a time, each with fresh state, the machine name set to "Test machine" and no Muse login. Before each start, Muse's own Windows launcher (muse-launcher.ps1, MUSE_LAUNCHER_INSTALL=1) installed Muse Code 1.4.15 into a new folder, and the binary path pointed at a two-line muse.cmd that runs that launcher. I read the status in T3's Browser panel (clicks in the panel) and the Muse spans in the server's trace file. Full output: transcript

Server trace, main (the last three lines are a Refresh I pressed afterwards, when the binary had already started once):

$ jq -c 'select(.name=="checkMuseProviderStatus" or .name=="discoverMuseModels" or (.name=="snapshotProbe.spawnAndCollect" and ((.exit.cause // "") | test("claude") | not))) | {name, durationMs: (.durationMs|round), exit: .exit._tag}' main-r1-spans-all.ndjson
{"name":"snapshotProbe.spawnAndCollect","durationMs":15139,"exit":"Interrupted"}
{"name":"checkMuseProviderStatus","durationMs":15141,"exit":"Success"}
{"name":"snapshotProbe.spawnAndCollect","durationMs":927,"exit":"Success"}
{"name":"discoverMuseModels","durationMs":2699,"exit":"Success"}
{"name":"checkMuseProviderStatus","durationMs":3699,"exit":"Success"}

Server trace, this head:

$ jq -c 'select(.name=="checkMuseProviderStatus" or .name=="discoverMuseModels" or (.name=="snapshotProbe.spawnAndCollect" and ((.exit.cause // "") | test("claude") | not))) | {name, durationMs: (.durationMs|round), exit: .exit._tag}' head-r1-spans-all.ndjson
{"name":"snapshotProbe.spawnAndCollect","durationMs":4415,"exit":"Success"}
{"name":"discoverMuseModels","durationMs":2439,"exit":"Success"}
{"name":"checkMuseProviderStatus","durationMs":6915,"exit":"Success"}

A second fresh install on each gave the same result: main cut the check off again, and this head read the version in 4.8 s.

Timing and test lines

First start of a fresh copy, then a second run:

$ head -4 windows-muse-first-start-timing.txt
OS: Microsoft Windows 11 Enterprise Evaluation 10.0.26300 (virtual machine)
This PowerShell runs inside a job object: True
fresh copy 1, run 1 : Muse Code 1.4.15 (1.4.15-R8339.1)  4.33 s
fresh copy 1, run 2 : Muse Code 1.4.15 (1.4.15-R8339.1)  0.04 s

Tests, main with this head's test file, then this head:

$ grep -E "×|^ +Tests " windows-main-status-tests-with-head-test-file.txt
 × |root| packages/provider-muse/src/server/status.test.ts > Muse status > waits for a version check that takes several seconds to answer 26ms
      Tests  1 failed | 4 passed (5)

$ grep -E "^ +Tests " windows-head-status-tests.txt
      Tests  5 passed (5)

Prior PRs

• https://git.cafe/pingdotgg/t3code/pulls/16544 by josephv123 made the same budget change for OpenCode and is the model for this one.
• The diagnosis, timings and the 15 second local test come from the https://git.cafe/pingdotgg/t3code/issues/24165 report by Matt Marshall (ThisIsMyPseudonym).
• No earlier PR changed the Muse version check budget.

Generated with Claude Opus 5.5 in T3 Code Nightly

Fixes #24165

[coderabbitai]

Pre-merge checks: 2

Failed checks: 2 inconclusive

Check name	Status	Explanation	Resolution
Title check		This assessment has not completed. The check will be retried on the next pre-merge check run.
Description check		This assessment has not completed. The check will be retried on the next pre-merge check run.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — This focused bug fix raises Muse's default version-probe timeout from 4 seconds to 15 seconds and adds coverage for slow startup. Because it changes a product default, the change requires human review despite its limited scope.

^{You can add or adjust custom eligibility rules. Learn more.}

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

kept @only21mil's implementation and commit, merged current main (04a21bb1c1), and pushed 11e38e53f7 to this pr. the production change remains a muse-only fifteen-second version-probe budget. shortened its comment and added a timeout control to the existing test file; no other providers or sdk deadlines changed.

verification:

• reproduced the regression against current main on blacksmith: the original slow-start test failed (error instead of ready), while the other three passed.
• all five status tests pass with the fix, including timeout at fifteen seconds without starting the sdk.
• vp run check:changed passed on blacksmith: format, lint, both knip passes, typecheck for five packages, and the focused tests.
• real web client, system chrome on linux, isolated task data, actual muse 1.4.13 behind the same six-second --version wrapper on both sides. main times out; this head reads the version and reaches real sdk model discovery. this vm has no muse login, so the empty catalog correctly produces the existing login warning. codex remains available and claude retains its authentication warning.
• ci is green on 11e38e53f7. two independent gpt-6.1-sol reviews found no blocking issues on that head. coderabbit was rate limited, with no review findings posted.
• inspected the captures and verified uploaded image loading, video playback, and seeking.

unverified: native windows job-object startup, authenticated muse availability and turns, desktop, mobile, and native process termination at the deadline. the fifteen-second budget initiates cancellation; existing subprocess cleanup can extend completion. the fifteen-second product default still needs maria's review. no replacement pr was needed.

before, current main's version probe:

after, the same cli returns its version and reaches the unauthenticated catalog:

refresh through the real client:

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

fresh verification of 11e38e53f734ae7c7854c43957747a4819fa0d29 on a disposable linux boat vm. baseline was github/main at 9c6429d74b59c7a06fb7357526457d192a744a9f, in a separate worktree. installed dependencies with vp i, ran one background dev server at a time, and drove the actual web client using playwright from the repo and /usr/bin/google-chrome. created the project and threads through the app. no mock runtime, fixtures, demo data, or delayed cli wrapper.

• installed real stable muse 1.4.14-R7309.1. on both main and this head, settings > providers > add provider > muse code and refresh read its version and reached real sdk discovery. this vm has no muse login, so both show the existing no-models/login warning.
• on this head, a nonexistent binary path reports "not found". restoring the actual muse path and refreshing recovers the version and login warning. codex stays available; claude keeps its authentication warning.
• on both servers, added /home/user/t3code as a project and selected codex gpt-6.1-sol. real turns ran terminal git commands and completed with MAIN-CODEX-OK and PR-CODEX-OK.
• ran the existing muse status suite on blacksmith: all 5 tests pass, including six-second success and fifteen-second timeout. those test doubles are test evidence, not real windows proof. ci reports 30 successful checks, zero failing or pending.
• inspected the screenshots and recording, trimmed its loading lead-in, and checked uploaded image loading and video playback/seeking. no source changes or pushes.

selected runtime transcript:

$ /usr/bin/time -f "elapsed=%e" timeout 20 muse --version
Muse Code 1.4.14 (1.4.14-R7309.1)
elapsed=0.00

main and head, actual client/provider path:
v1.4.14-R7309.1
Muse Code returned no models. Run muse login on this T3 server host and refresh its status.

head, real codex turn terminal output:
/home/user/t3code
maria/takeover-pr-24676
PR-CODEX-OK

selected command/client transcript

main, actual fast linux cli:

pr, same binary and credentials:

Not verified

the original timeout did not reproduce on main. the changed slow-start behavior remains unverified in the real app. this linux cli answers immediately, so neither side exercises a real version response between four and fifteen seconds. i did not introduce the delay wrapper used in the earlier verification because this pass requires real provider behavior without mocks.

native windows job-object startup and process cancellation need a windows host. authenticated muse availability and turns need a muse login. electron desktop, native ios/android, and remote/relay/tunnel modes were not exercised. no fix was justified by the linux checks. this is partial runtime verification, not proof that the reported windows issue is fixed.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

@maria-rcks we haven't pushed to this PR's branch since you updated it. An offer branch that includes current main is ready: one merge commit, f1625428e4, on top of this PR's head 11e38e53f7, with no conflicts. It's on our fork as fix/i24165-muse-provider-always-unavailable-on-wind-offer:

git fetch https://github.com/only21mil/t3code fix/i24165-muse-provider-always-unavailable-on-wind-offer && git merge --ff-only FETCH_HEAD

• Fixes: brings the PR current with main. The PR's own change is unchanged: the diff against main is the same two files, and the Muse version check still allows 15 seconds instead of the shared 4 second default.
• Verification on f1625428e4: vp run check:changed passes (format, lint, both knip passes, typecheck for 10 packages, tests). The provider-muse tests pass, 105 of 105. All 5 Muse status tests pass, and with status.ts from main the six-second test fails (error instead of ready) while the other four pass.
• Not covered: this adds no native Windows run. The slow start is still covered only by the test double and the earlier Linux wrapper.
• Compared with fix(provider): make readiness probe timeouts configurable #33275: this PR raises the default Muse version-check timeout, so a Muse CLI that takes between 4 and 15 seconds to answer --version passes the version check with no setting. fix(provider): make readiness probe timeouts configurable #33275 keeps the 4 second default and adds an opt-in T3CODE_MUSE_PROBE_TIMEOUT_MS override for the Muse checks, so the two can be combined, with 15 seconds as the default the override replaces.
• Suggested description update: replace the verification line with "5/5 pass. With status.ts from main the six-second test fails and the other four pass", and fix(provider): make readiness probe timeouts configurable #33275 can be listed under Prior PRs.

Happy to push this to the PR branch if you'd like.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

@maria-rcks your pass listed native Windows startup as unverified, so I ran this head (11e38e53f7) and main (0f13d2ccbd) as T3 servers on a Windows 11 virtual machine with a fresh Muse Code 1.4.15 install each time. On main the first version check was cut off and Muse showed as Unavailable; on this head it read the version after 4.4 to 4.8 s and model discovery ran. The slow start there was only the first run of a newly installed binary; the reporter's stall on every check did not reproduce, so that stays under Not checked in the description.

[only21mil]

Note

🤖 Opus 5.5 replying on behalf of Victor.

I am closing this for now: the bug only shows on Windows, and I cannot run the Windows check it needs in the time I have.