Synced from GitHub
Pre-merge checks: Inconclusive 2
-
Failed Failed checks: 2 inconclusive
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
fix(muse): slow Windows starts no longer show Muse as unavailable#24676
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. 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.
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.
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.
Scope and approval
Fixes https://git.cafe/pingdotgg/t3code/issues/24165. No maintainer has commented on the issue yet, so this change awaits maintainer review. 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. This PR is that fix and nothing else. It does not keep a ready snapshot through a slow check or change any other provider. For maintainers to confirm: a Muse-only 15 second budget, rather than a higher shared default for every provider.
Verification
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
- A slow Windows start no longer shows Muse as unavailable. On this machine the first
--versionof 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.
Server trace, main (the last three lines are a Refresh I pressed afterwards, when the binary had already started once):
text
| 1 | $ 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 |
| 2 | {"name":"snapshotProbe.spawnAndCollect","durationMs":15139,"exit":"Interrupted"} |
| 3 | {"name":"checkMuseProviderStatus","durationMs":15141,"exit":"Success"} |
| 4 | {"name":"snapshotProbe.spawnAndCollect","durationMs":927,"exit":"Success"} |
| 5 | {"name":"discoverMuseModels","durationMs":2699,"exit":"Success"} |
| 6 | {"name":"checkMuseProviderStatus","durationMs":3699,"exit":"Success"} |
Server trace, this head:
text
| 1 | $ 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 |
| 2 | {"name":"snapshotProbe.spawnAndCollect","durationMs":4415,"exit":"Success"} |
| 3 | {"name":"discoverMuseModels","durationMs":2439,"exit":"Success"} |
| 4 | {"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.
- The new test fails on
mainand passes on this head, on the same machine. I ran this head first, thenmainwith only this head's test file copied in.mainfails "waits for a version check that takes several seconds to answer"; this head passes all 5.
Timing and test lines
First start of a fresh copy, then a second run:
text
| 1 | $ head -4 windows-muse-first-start-timing.txt |
| 2 | OS: Microsoft Windows 11 Enterprise Evaluation 10.0.26300 (virtual machine) |
| 3 | This PowerShell runs inside a job object: True |
| 4 | fresh copy 1, run 1 : Muse Code 1.4.15 (1.4.15-R8339.1) 4.33 s |
| 5 | 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:
text
| 1 | $ grep -E "×|^ +Tests " windows-main-status-tests-with-head-test-file.txt |
| 2 | × |root| packages/provider-muse/src/server/status.test.ts > Muse status > waits for a version check that takes several seconds to answer 26ms |
| 3 | Tests 1 failed | 4 passed (5) |
text
| 1 | $ grep -E "^ +Tests " windows-head-status-tests.txt |
| 2 | Tests 5 passed (5) |
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.
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 pingdotgg/t3code#24165
Checks
22 successful · 8 skipped
Added 1 commit
- fix(muse): slow Windows starts no longer show Muse as unavailable939afac
Synced from GitHub
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.
Added 2 commits
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 (
errorinstead ofready), 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:changedpassed 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
--versionwrapper 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:
main: the six-second Muse version probe times out
after, the same cli returns its version and reaches the unauthenticated catalog:
head: Muse version is read and the existing login warning is shown
refresh through the real client:
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/t3codeas a project and selected codexgpt-6.1-sol. real turns ran terminal git commands and completed withMAIN-CODEX-OKandPR-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:
text
| 1 | $ /usr/bin/time -f "elapsed=%e" timeout 20 muse --version |
| 2 | Muse Code 1.4.14 (1.4.14-R7309.1) |
| 3 | elapsed=0.00 |
| 4 | |
| 5 | main and head, actual client/provider path: |
| 6 | v1.4.14-R7309.1 |
| 7 | Muse Code returned no models. Run muse login on this T3 server host and refresh its status. |
| 8 | |
| 9 | head, real codex turn terminal output: |
| 10 | /home/user/t3code |
| 11 | maria/takeover-pr-24676 |
| 12 | PR-CODEX-OK |
selected command/client transcript
main, actual fast linux cli:
main reads the real muse version and shows its login warning
pr, same binary and credentials:
pr reads the real muse version and shows the same login warning
pr recovers from a missing binary after restoring the real muse path and refreshing
real gpt-6.1-sol turn completes through the pr web client and server
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.
Synced from GitHub
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:
| 1 | 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 againstmainis 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:changedpasses (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 withstatus.tsfrommainthe six-second test fails (errorinstead ofready) 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 #33275: this PR raises the default Muse version-check timeout, so a Muse CLI that takes between 4 and 15 seconds to answer
--versionpasses the version check with no setting. #33275 keeps the 4 second default and adds an opt-inT3CODE_MUSE_PROBE_TIMEOUT_MSoverride 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.tsfrommainthe six-second test fails and the other four pass", and #33275 can be listed under Prior PRs.
Happy to push this to the PR branch if you'd like.
Synced from GitHub
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.