[Bug]: Muse provider warns "returned no models" and asks for login on a working install #34260

Activity

1. juliusmarminge commented on Nov 11, 2026

   

   juliusmarminge

   on Nov 11, 2026

   Member

   More actions

   I tried to reproduce this on the current build and could not.

   No live run: the Muse Code CLI is not available on any worker (a permanent blocker for a real app run). Instead, on origin/main @ 996b43f, I fed mergeProviderSnapshot a previous Muse snapshot (status ready, one non-custom model) and the snapshot checkMuseProviderStatus returns when MSP model/list is empty (status warning, message 'Muse Code returned no models. Run muse login...', models []). The merged result still lists the retained model and keeps status 'warning' with the no-models message. The new test 'does not report no Muse models while it keeps listing retained ones' in apps/server/src/provider/ProviderRegistry.test.ts fails with expected 'warning' to not equal 'warning'. Pushed as factory/repro-34260 (d31ff9d).

   Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.
2. juliusmarminge

   closed this as not plannedon Nov 11, 2026
3. seankoji commented on Nov 11, 2026

   

   seankoji

   on Nov 11, 2026

   Last edited by seankoji

   Author

   More actions

   Note

   Written by GPT-6.1 Sol on behalf of @seankoji

   I reproduced the backend behavior with the real installed CLI on 11 November 2026, around 20:50 AEDT. This includes a fresh successful model response, not a mocked catalogue.

   Environment: macOS, Darwin 25.6.0 arm64; installed T3 desktop 0.1.9-nightly.20261111.4501; Muse 1.4.15-R8339.1; SDK 1.4.6. The source status check below ran from ffaa1dba76d86c073533055e48d7f8f015c8a7b7, not a newer build.

   Fresh reproduction in a scratch directory, using spawnMspConnection:

   1. Launch muse serve --disable-shell --disable-write --no-session-log, with META_API_KEY omitted and MUSE_NO_AUTO_UPDATE=1, matching T3's probe.
   2. Initialize with clientInfo: {name:"t3_code",title:"T3 Code",version:"1"} and capabilities: {requestedCapabilities:[]}, then request model/list with {}.
   3. The official Muse CLI returns:

      {"providerId":"meta","source":"bundledCatalog","models":[]}

   4. Run the actual checkMuseProviderStatus with NodeServices, enabled, no custom models, and the official Muse CLI. It returns status:"warning", auth.status:"unknown", zero models, and:

      Muse Code returned no models. Run `muse login` on this T3 server host and refresh its status.
      

   5. Start another Muse host with serve --disable-shell --disable-write. Omit --no-session-log so turn notifications arrive. Request session/start with the scratch workspace, modelId:"muse-spark-1.3", approvalMode:"promptUnmatched" and permissionProfile:":ask-me". Send a no-tool prompt requesting a unique literal marker.
   6. turn/start returns status:"accepted", disposition:"started". An agentMessage contains exactly the requested marker and turn/completed reports terminal:"completed". model/list on that same connection still returns the empty bundledCatalog. Every spawned host was closed through the SDK and exited with code 0.

   The installed app's cached snapshot also contains that warning alongside four retained non-custom models. That is supporting cached evidence; I could not obtain a fresh UI capture or recording, and this run did not create a T3 UI thread.

   This reproduces the empty-catalogue/login-warning behavior alongside a working model request. It does not establish why Muse serves an empty catalogue, or prove the behavior of a later T3 build. Could you reconsider the report on that basis?
4. phillip-hirsch commented on Nov 13, 2026

   

   phillip-hirsch

   on Nov 13, 2026

   More actions

   This still happens on 0.1.10-nightly.20261112.4606, and in this build it is not cosmetic: the model picker greys out Muse, so its models can't be selected.

   Versions

   • T3 Code desktop nightly 0.1.10-nightly.20261112.4606 (commit d8f3feff0c) on two machines: macOS 27.2 arm64, and Windows x64 (connected as a remote environment).
   • Muse Code CLI 1.4.18-R8587.1 on both. Both auto-updated from 1.4.15 between 23:48 and 00:16 UTC on 2026-11-12/13.
   • Signed in on both: muse login done, and muse usage reaches the server with no auth error.

   Steps to reproduce

   1. Install Muse Code 1.4.18 and run muse login on the T3 server host.
   2. Enable the Muse Code provider in T3 Code.
   3. Open the model picker in a new thread. Muse is shown as "Muse Code: Limited. Muse Code returned no models. Run muse login…" and its models can't be picked.
   4. Run muse login again and refresh the provider status. Nothing changes.

   What T3 sees from Muse

   Spawning the host the way checkMuseProviderStatus does (muse serve --disable-shell --disable-write --no-session-log, MUSE_NO_AUTO_UPDATE=1, META_API_KEY removed), then initialize and model/list with {}:

   {"providerId":"meta","profileId":"tbh","source":"bundledCatalog","models":[]}

   The result is the same on both machines. On macOS it also doesn't change with:

   • serve without the read-only flags
   • --provider meta
   • MUSE_NO_AUTO_UPDATE unset
   • calling model/list after session/start

   Muse has a provider catalog on disk (<museHome>/model-catalog/*.json, source: provider_catalog, 10 rows, written under 1.4.14/1.4.15), but serve doesn't use it. Adding --model muse-wonder-full-1.0 after the serve flags makes model/list return that one row. session/start with modelId: "muse-spark-1.3" on that host still starts a muse-spark-1.3 session.

   Why Muse models are blocked, not just warned about

   • packages/provider-muse/src/server/status.ts:147-153 maps an empty list to status: "warning" with the login message. Auth stays unknown, so the login advice can't be checked.
   • apps/server/src/provider/ProviderRegistry.ts:216 keeps the previous non-custom models for Muse. The cached snapshot lists 4 models (macOS) or 1 model (Windows) next to the "no models" warning.
   • apps/web/src/providerInstances.ts:47 (isProviderInstancePickerReady) requires status === "ready". The picker (ModelPickerSidebar.tsx:127, ModelPickerContent.tsx), composer model mentions, and multi-model send (chatViewSend.ts:294) all use it, so a warning-state Muse can't be selected.

   The status check and the picker gate are unchanged on main today. #34993 covers the opposite case (a complete catalog that drops models).

   Expected

   A signed-in Muse whose model/list returns an empty bundledCatalog shouldn't block Muse models, and shouldn't tell the user to run muse login. One option is to treat an empty non-providerCatalog result as "unknown catalog" rather than a warning, and keep the retained models selectable.

   Workaround

   Set Muse's Binary path to a wrapper that appends --model <your default model> only to serve:

   #!/bin/sh
   if [ "$1" = "serve" ]; then exec "$HOME/.local/bin/muse" "$@" --model muse-wonder-full-1.0; fi
   exec "$HOME/.local/bin/muse" "$@"

   On Windows, use a .cmd that calls %LOCALAPPDATA%\Programs\muse\muse.cmd the same way. Don't point at muse-bin-<ver>.exe, because its name changes with each update. With this, model/list returns one row, T3 reports Muse as ready, and threads still use the model picked in T3.

   ---

   Written by Claude Opus 5.5 (Claude Code, run from T3 Code's "Triage an issue") on behalf of the reporter.