Reproduced on Ubuntu Linux x86_64 at main 70e5e384da. The isolated mise 2026.10.14 install succeeds with only the launcher present; MUSE_NO_AUTO_UPDATE=1 muse --version exits 1 with muse: installed binary is missing; rerun the installer. The real web dev app, using isolated state and this binary path, shows only the generic unavailable message. On a separate fresh launcher, ordinary muse --version initializes the runtime; the subsequent no-auto-update probe succeeds. No Omarchy system upgrade was performed.
[Bug]: Muse fails after Omarchy mise upgrade because MUSE_NO_AUTO_UPDATE blocks runtime bootstrap and stderr is discarded#22299
Area
apps/server
Summary
After omarchy update upgrades the mise-managed Muse installation, T3 disables Muse with Muse Code CLI is installed but failed to run. The newly installed Muse directory contains the launcher but no runtime binary. T3 sets MUSE_NO_AUTO_UPDATE=1, which prevents the launcher from completing its first-run installation.
The launcher's actionable stderr is muse: installed binary is missing; rerun the installer. T3 drops that stderr and the exit code from the provider status, leaving no explanation in the UI.
Steps to reproduce
The affected system uses Omarchy's standard Muse wrapper, installed through the HTTP mise backend. This isolated reproduction does not upgrade the system or change the existing Muse installation:
bash
| 1 | repro_dir=$(mktemp -d) |
| 2 | export MISE_DATA_DIR="$repro_dir/data" |
| 3 | export MISE_CACHE_DIR="$repro_dir/cache" |
| 4 | export MISE_CONFIG_DIR="$repro_dir/config" |
| 5 | export MISE_MINIMUM_RELEASE_AGE=0 |
| 6 | mise install 'http:muse[url=https://api.meta.ai/muse-launcher.sh,bin=muse,version_list_url=https://api.meta.ai/muse-code/channels/muse-stable,version_json_path=.version]@1.4.11-R6667.1' |
| 7 | ls -la "$MISE_DATA_DIR/installs/http-muse/1.4.11-R6667.1" |
| 8 | MUSE_NO_AUTO_UPDATE=1 "$MISE_DATA_DIR/installs/http-muse/1.4.11-R6667.1/muse" --version |
Actual recorded results:
text
| 1 | mise install exit code: 0 |
| 2 | Installed directory files: muse |
| 3 | Version probe exit code: 1 |
| 4 | Version probe stdout: empty |
| 5 | Version probe stderr: muse: installed binary is missing; rerun the installer |
The end-user trigger is to run omarchy update, let mise up upgrade Muse to a new directory, then refresh the Muse provider before starting Muse manually in a terminal. The user reports that this recurs after updates. The isolated install-and-probe sequence above was reproduced during this investigation.
Expected behavior
T3 can handle a Muse installation that needs first-run initialization, or presents an actionable setup error. Diagnostics preserve a bounded, sanitized stderr excerpt and the nonzero exit code.
Disabling automatic updates for an initialized runtime should not make an installed launcher look like an unexplained broken CLI.
Actual behavior and evidence
The update log records:
text
| 1 | Upgraded 2 tools: |
| 2 | claude 2.1.302 → 2.1.304 |
| 3 | http:muse 1.4.10-R6427.1 → 1.4.11-R6667.1 |
| 4 | Script done on 2026-10-20 19:34:22+08:00 [COMMAND_EXIT_CODE="0"] |
T3's persisted Muse snapshot at 2026-10-20T11:35:43.728Z contains:
json
| 1 | { |
| 2 | "instanceId": "muse", |
| 3 | "driver": "muse", |
| 4 | "enabled": true, |
| 5 | "installed": true, |
| 6 | "version": null, |
| 7 | "status": "error", |
| 8 | "auth": { "status": "unknown" }, |
| 9 | "message": "Muse Code CLI is installed but failed to run." |
| 10 | } |
The trace span for that check completed in 64.154631 ms with Effect exit Success. That means the status function returned a snapshot; it does not mean the CLI succeeded. This was not the version-probe timeout branch.
During diagnosis, running ordinary muse --version initialized the current installation. The new directory then contained .muse-version and muse-bin-1.4.11-R6667.1. Both ordinary and MUSE_NO_AUTO_UPDATE=1 version probes subsequently returned exit 0 and Muse Code 1.4.11 (1.4.11-R6667.1). The original incident's subprocess stderr was not retained by T3. The fresh isolated reproduction supplies the missing error and establishes the installation mechanism. A T3 UI refresh after initialization has not been verified.
Relevant code
The installed release resolves to commit d36b7da2485bc889b320a285deea181f637d760a.
- makeMuseEnvironment sets
MUSE_NO_AUTO_UPDATE=1. - checkMuseProviderStatus runs
--version, then replaces nonzero output with the generic failure message. - The downloaded
https://api.meta.ai/muse-launcher.shchecks for its sibling runtime. When that runtime is absent andMUSE_NO_AUTO_UPDATE=1, it exits with the error reproduced above.
Environment
- T3 Code
0.1.1-nightly.20261020.3411. - Omarchy
4.0.6-1, upgraded from4.0.5-1. - Arch Linux, kernel
7.2.8-9-omarchy, x86_64. - mise
2026.10.14, package upgraded from2026.10.12-1to2026.10.14-1. - Muse
1.4.11-R6667.1, upgraded from1.4.10-R6427.1. - AMD Ryzen 5 4600H, Radeon RX 5500M and integrated Radeon graphics.
- Muse provider enabled with the default binary path and no provider environment overrides.
Workaround
Run muse --version once in a terminal to let the new launcher install its runtime, then refresh the Muse provider in T3. The CLI initialization was verified here. The final UI refresh remains unverified.
Related reports
Searched existing Muse and exact-error reports before filing. #7230 concerns cached timeout failures. #16106 concerns Claude and Codex probes through mise. This report has a deterministic nonzero Muse launcher exit caused by an uninitialized installation.
Relevant update logs, the provider snapshot, health traces, and Omarchy diagnostics were collected locally. This report includes sanitized excerpts and a minimal reproduction. Full application traces, session data, credentials, network identifiers, and private system diagnostics are not uploaded.
The corresponding Omarchy packaging report is https://github.com/omacom/omarchy/issues/16062.