Description

On WSL2, when Ollama is installed at %LOCALAPPDATA%\Programs\Ollama\ollama.exe but is not running and not in the Windows PATH, the nemoclaw onboard inference menu shows "Install Ollama on Windows host (recommended)" instead of the expected "Start Ollama on Windows host (suggested)". The root cause is in probeInstalledPath() (src/lib/onboard/windows-host-ollama.ts line 63): the GET_KNOWN_OLLAMA_INSTALL_PATH filesystem check is gated behind a PID guard (if (!pid) return "") and is only reachable when Ollama is running. When Ollama is installed but not running and not in PATH, pid is empty and the function returns "" early, causing installed=false and surfacing the wrong "Install" menu option.

Environment

Device:        Windows 11 host + WSL2 (Ubuntu 24.04)
OS:            Ubuntu 24.04.4 LTS (Noble Numbat) in WSL2
Architecture:  x86_64
Node.js:       v22.22.3
npm:           10.9.8
Docker:        running in WSL2
OpenShell CLI: openshell 0.0.39
NemoClaw:      nemoclaw v0.0.49
OpenClaw:      v2026.4.24

Steps to Reproduce

1. On Windows host: install Ollama via OllamaSetup.exe /VERYSILENT
   • Binary exists at %LOCALAPPDATA%\Programs\Ollama\ollama.exe
   • Ollama is NOT in Windows PATH (Get-Command ollama returns empty)
   • Ollama service is NOT running (port 11434 not listening)
2. From WSL2: verify pre-condition — curl http://host.docker.internal:11434/api/tags fails
3. From WSL2: run nemoclaw onboard --fresh --name test-sandbox
4. At [3/8] Configuring inference provider, observe the inference menu options

Expected Result

Inference menu includes "Start Ollama on Windows host (suggested)" since Ollama binary exists at %LOCALAPPDATA%\Programs\Ollama\ollama.exe.

Per design in onboard.ts: when hasWindowsOllama===true AND Ollama is not reachable AND not loopback-only, the menu should show "Start Ollama on Windows host (suggested)".

Actual Result

Inference menu shows:

7) Install Ollama on Windows host (recommended)

The "Start Ollama on Windows host (suggested)" variant is absent.

Root cause trace (windows-host-ollama.ts lines 47–84):

probeInstalledPath():
  1. Get-Command ollama.exe → "" (not in PATH)
  2. Get-Process ollama Path → "" (not running)
  3. Get-Process ollama Id  → "" (not running, no PID)
  4. if (!pid) return ""    ← RETURNS HERE, never reaches filesystem check
  5. GET_KNOWN_OLLAMA_INSTALL_PATH ← UNREACHABLE when not running

installed = ("".length > 0) → false → "Install" menu shown instead of "Start"

GET_KNOWN_OLLAMA_INSTALL_PATH (the $LOCALAPPDATA\Programs\Ollama\ollama.exe filesystem check) is only reachable when there is a live ollama PID — i.e. when Ollama IS running. The installed-but-not-running case falls through incorrectly.

Proposed fix: move GET_KNOWN_OLLAMA_INSTALL_PATH check before the PID gate:

const knownPath = powershell(GET_KNOWN_OLLAMA_INSTALL_PATH);
if (knownPath.length > 0) return knownPath;
if (!pid) return "";

Related (but distinct): NVB#6196866 added the Get-Process fallback for PATH-miss cases when Ollama IS running. This bug is the complementary case: not running.

Logs

Code analysis of src/lib/onboard/windows-host-ollama.ts lines 47-84.

Key lines:
  62:  const pid = powershell(GET_PROCESS_OLLAMA_ID);
  63:  if (!pid) return "";
  64:  return powershell(GET_KNOWN_OLLAMA_INSTALL_PATH);

Test-Path "$env:LOCALAPPDATA\Programs\Ollama\ollama.exe" = True (verified during testing)
Get-Command ollama = empty (not in PATH after /VERYSILENT install)
netstat -ano | findstr :11434 = no output (Ollama not running)

NVB#6205829