[Bug]: Windows LM Studio installation remains at 75% and is not detected after successful llmster install #13

Activity

1. GrandMasterTurtle commented on Sep 6, 2026

   

   GrandMasterTurtle

   on Sep 6, 2026

   More actions

   I am experiencing what appears to be the same LM Studio engine-management issue on macOS / Apple Silicon, with an additional failure after detection succeeds.

   Environment

   • PAIR: 0.1.1 (0.1.1.463)
   • OS: macOS / Apple Silicon
   • Hardware: MacBook Pro M3 Max, 128 GB
   • LM Studio CLI: Official install script

   Reproduction

   1. PAIR's LM Studio Download/install reaches 75% and hangs.
   2. Installing LM Studio manually with the official installer succeeds.
   3. I exposed the installed lms binary through /usr/local/bin and reset PAIR app data.
   4. After restarting, PAIR successfully detects the existing LM Studio installation.
   5. Clicking Start then leaves PAIR indefinitely stuck on starting....

   I also verified that ports 1234/1235 are free and that no existing lms processes are running, so this does not appear to be a port conflict or already-running daemon.

   Key isolation finding

   The manual installation + symlink proves that PAIR can detect the LM Studio installation on macOS. However, PAIR still cannot launch the engine after detection succeeds.

   The behavior is therefore:

   PAIR installation → 75% → detection failure
   
   Manual installation → PAIR detects engine → Start → "starting..." indefinitely
   

   This suggests the problem may extend beyond installation/discovery into PAIR's engine process/background-service startup.

   I also see this macOS helper error:

   {"level":"error","source":"app","sublevel":"mac-helper","message":"Privileged helper setup incomplete: enabled Couldn’t communicate with a helper application."}
   

   I can't confirm that the helper is the root cause, but it seems potentially relevant to the failed Start operation.

   Why I'm commenting here

   This seems related to #13 because both cases involve PAIR's LM Studio lifecycle failing around the 75% installation/detection stage, while the underlying LM Studio installation itself works.

   My macOS reproduction provides an additional data point: even after successfully satisfying PAIR's engine detection, the subsequent Start operation still fails.

   It may be worth investigating PAIR's cross-platform LM Studio engine lifecycle, particularly executable resolution, background-process spawning/management, readiness detection, and macOS privileged-helper handling.

   Sanitized installation error:

   Failed to install lmstudio: -32000: engine "lmstudio" was not detected after install
   
2. MGStudio02 commented on Sep 7, 2026

   

   MGStudio02

   on Sep 7, 2026

   More actions

   nvpair-sanitized.log

   Confirming this also reproduces on macOS (Apple Silicon, M2 Max, arm64 native — not Rosetta), so it isn't Windows-specific.

   PAIR version: 0.1.1 LM Studio CLI / llmster: same version as above — llmster 0.0.23-1

   My repro is slightly different — fresh install, no pre-existing LM Studio — but the failure signature is identical: stuck at 75% (installing), then fails with engine "lmstudio" was not detected after install, with PAIR's proxy correctly holding port 1234 while 127.0.0.1:1235 stays unhealthy.

   I dug one level further into why the backend at 1235 is unhealthy. Running lms daemon status confirms llmster is genuinely running:
   llmster v0.0.23+1 is running (PID: 46026)

   But checking what that process actually has open (lsof -p 46026), it is not listening on port 1234 or 1235 at all:
   llmster 46026 ... TCP localhost:41343 (LISTEN)
   llmster 46026 ... TCP localhost:search-agent (LISTEN)

   So lms daemon up starts the background daemon, but does not appear to start the actual OpenAI-compatible serving API on the port PAIR assigns/expects. That matches the "backend not registered or kept running" behavior described above — PAIR's nvpair-engine-manager may be missing a separate "start serving" step (possibly lms server start) beyond just bringing the daemon up, or its health check should target whatever port llmster actually reports via lms status rather than assuming the fixed port it assigned.
   My sanitized nvpair.jsonl shows the identical 75%→failed progression across three separate attempts.

   Possibly related: lmstudio-ai/lmstudio-bug-tracker#1720 — lms server status misreporting server state on Linux, suggesting llmster's own self-reporting may be unreliable independent of PAIR.
3. cruzanstx commented on Sep 7, 2026

   

   cruzanstx

   on Sep 7, 2026

   Author

   More actions

   Confirming cross-platform from my side as well — my original report was Windows 11 x64 (PAIR 0.91.7, llmster 0.0.23-1), and the two new macOS repros (@GrandMasterTurtle M3 Max, @MGStudio02 M2 Max) share the identical failure signature:

   • install reaches 75% (installing) and stalls ~108s
   • official install.ps1 / manual install succeeds and the llmster binary lands on disk and PATH
   • PAIR still reports engine "lmstudio" was not detected after install
   • PAIR's proxy holds port 1234 while its expected backend at 127.0.0.1:1235 stays healthy=false and unregistered
   • engine-state.json never gains the lmstudio entry

   Since the installer completes on both OSes and the binary is present and executable, this looks like PAIR's post-install detection/registration step failing, not the download/install itself. Detection is presumably PATH- or default-path-based and is missing the ~/.cache/lm-studio/llmster/<ver> install location on both platforms (or the daemon-handshake step times out and isn't retried).

   Flagging for triage: this now reproduces on Windows 11 + macOS arm64 (M2 and M3), so it's cross-platform and likely not environment-specific. Happy to run a debug build or collect engine-manager/proxy debug-level logs from the Windows machine if useful.
4. Noah-Tervalon-Nvidia

   assigned

   ckelseynv

   on Sep 11, 2026
5. Noah-Tervalon-Nvidia commented on Sep 11, 2026

   

   Noah-Tervalon-Nvidia

   on Sep 11, 2026

   Collaborator

   More actions

   So this is a reporting problem. We stick lms at 75% while we are installing it for a handful of reasons, but it's not actually stuck. You may just have to wait for it to finish installing. We will update it to either give a percentage if we can get one, or report that it's just installing iwth no commitment on a number. @ckelseynv

   Also, given your repro steps it looks like after you reinstalled you didn't start the engine. If an engine exists, but isn't running we can't detect it and aren't going to crawl all of a user's directories to try to find binaries for engines we might want to use.
6. eoffermann commented on Sep 12, 2026

   

   eoffermann

   on Sep 12, 2026

   More actions

   @Noah-Tervalon-Nvidia - Here's what's actually happening. The percentage is misleading (because basically nothing has been installed when it hits 75%) but I've reproduced this across three different windows machines and the same action fixed it:

   On systems with an existing LM Studio installation whose home directory has been relocated, PAIR reports the lmstudio engine as installed: false and every install attempt ends with engine "lmstudio" was not detected after install. The install itself is not failing. PAIR downloads and runs https://lmstudio.ai/install.ps1, which resolves the install target by reading %USERPROFILE%\.lmstudio-home-pointer and falling back to <home>\.lmstudio only when that file is absent. On my machines the pointer contains C:\Users\<user>\.cache\lm-studio, so lms.exe is placed at C:\Users\<user>\.cache\lm-studio\bin\lms.exe and nothing is ever written to C:\Users\<user>\.lmstudio\bin\lms.exe, which is the path PAIR probes. The installer honors the pointer; PAIR's detection does not. Reproduced on three separate Windows machines, all with pre-existing LM Studio installs, all failing identically. Ollama on the same machines detects and installs normally.

   Two things make this hard to diagnose from logs. The engine manager emits no DEBUG output for the install path at any log level, so the installer's stdout, stderr, and exit code are never captured, and neither are the paths the detection step checked. The only trace is the final failure string roughly 165 to 255 seconds after the attempt begins. Separately, during each attempt the local model-enrichment endpoint at 127.0.0.1:14322/v1/models stops responding for the full duration of the install (context deadline exceeded), recovering only after the attempt fails. That may be an independent issue but it is reproducible in the same window.

   Workaround: a directory junction from the expected path to the real one, mklink /J "C:\Users\<user>\.lmstudio" "C:\Users\<user>\.cache\lm-studio", which requires no admin rights. This fixed detection immediately on all three machines with no other changes. The proper fix is for the lmstudio engine manifest's detection logic to resolve the LM Studio home the same way the official installer does: read %USERPROFILE%\.lmstudio-home-pointer (and $HOME ahead of %USERPROFILE%, which the installer also prefers) and use <resolved home>\bin\lms.exe, falling back to the current hardcoded path only when no pointer exists.
7. cruzanstx commented on Sep 29, 2026

   

   cruzanstx

   on Sep 29, 2026

   Author

   More actions

   Confirming @eoffermann's root cause from my Windows 11 machine — the relocated-home detail explains my original report exactly:

   • %USERPROFILE%\.lmstudio-home-pointer exists on my machine and points into a relocated home, so the official install.ps1 placed lms.exe under the pointer target — never under C:\Users\<user>\.lmstudio\bin\, which is what PAIR probes.
   • The directory-junction workaround (mklink /J from the probed path to the real one) fixed detection immediately, same as on @eoffermann's three machines.

   That's now this signature reproduced on Windows 11 x64 + macOS arm64 (M2 and M3 Max), so it's cross-platform and matches a single cause: PAIR's detection hardcodes <home>\.lmstudio while the official installer honors .lmstudio-home-pointer. As @eoffermann says, the proper fix is for the lmstudio engine manifest to resolve the home the same way the installer does (pointer file first, $HOME before %USERPROFILE%, fallback to the current path only when no pointer exists).

   Seconding the observability point as well: zero DEBUG output on the install path (no installer stdout/stderr/exit code, no list of probed paths) is what made this take three machines and a junction experiment to bisect. Logging the resolved-vs-probed paths would have made this a one-report fix.

   One addition for the mac side of the thread: the post-detection "starting..." hang @GrandMasterTurtle hit is a distinct second failure (privileged helper communication), separate from the pointer/detection path — worth its own issue so the two don't blur together in triage.