feat(onboard): add WSL Windows-host Ollama install/start/restart flow#2800
Merged
Conversation
Signed-off-by: zyang-dev <267119621+zyang-dev@users.noreply.github.com>
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds a setter to override the resolved Ollama host; tightens probe/warmup prompts and generation limits; implements Windows-host Ollama onboarding from WSL (install/start/switch via PowerShell) with host detection and polling; centralizes Ollama model selection/validation and adds host-dependent tests. Changes
Sequence DiagramsequenceDiagram
participant User as Onboarding Wizard
participant WSL as WSL Discovery
participant PS as PowerShell (Windows Host)
participant WinSvc as Windows Ollama Watcher/Daemon
participant Daemon as Ollama HTTP API
participant LI as Local Inference
User->>WSL: start discovery / choose provider
WSL->>Daemon: probe /api/tags on candidate host(s)
alt Windows-host install/start selected
User->>PS: run install/start via powershell.exe
PS->>WinSvc: stop watcher, persist OLLAMA_HOST, start daemon
PS->>Daemon: poll host.docker.internal for readiness (max 15 attempts)
Daemon-->>PS: HTTP ready
PS->>LI: setResolvedOllamaHost(OLLAMA_HOST_DOCKER_INTERNAL)
end
User->>LI: selectAndValidateOllamaModel
LI->>Daemon: model probe (short prompt, options.num_predict=16)
Daemon-->>LI: probe response (validation)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 👉 Get your free trial and get 200 agent minutes per Slack user (a $50 value). Comment |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
src/lib/local-inference.ts (1)
434-463: ⚡ Quick winAdd regression tests for host-pinned model discovery behavior.
Please add/extend unit tests for:
setResolvedOllamaHost(OLLAMA_HOST_DOCKER_INTERNAL)+ empty/api/tags=> returns[](noollama listfallback), and- loopback host + empty
/api/tags=> still falls back toollama list.This branch is now critical to onboarding correctness and is worth pinning with explicit tests.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/local-inference.ts` around lines 434 - 463, Add unit tests for getOllamaModelOptions covering two host scenarios: (1) call setResolvedOllamaHost(OLLAMA_HOST_DOCKER_INTERNAL), mock the capture used by getOllamaModelOptions (or pass a runCaptureImpl) to return empty for the /api/tags endpoint and assert the function returns [] and does not call the "ollama list" fallback (e.g. by having the list capture throw or record calls); and (2) call setResolvedOllamaHost(OLLAMA_LOCALHOST), mock capture so the /api/tags response is empty but the "ollama list" capture returns a known value, then assert getOllamaModelOptions returns the parsed list (use parseOllamaList expected output). Ensure tests reset the resolved host after each case and use the getOllamaModelOptions/runCaptureImpl, parseOllamaTags, parseOllamaList symbols to locate and wire mocks.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/lib/onboard-windows-ollama.ts`:
- Around line 39-41: The current child process error handler swallows spawn
errors by resolving the promise in child.on("error", ...); update the handler
for the spawned child (the child variable and its "error" event) to log the
error (using the existing logger or console.error) and reject the promise with
the error instead of resolving, so callers can see and handle spawn failures and
logs contain the actual error details.
In `@src/lib/onboard.ts`:
- Around line 4721-4740: The WSL-specific install option currently uses the same
"install-ollama" key/flow as non-WSL, causing the post-install startup to run
the non-WSL path (setting OLLAMA_HOST=0.0.0.0 and starting the auth proxy) which
is unreachable from the sandbox; change the option pushed when isWsl() true to
use a distinct key (e.g., "install-ollama-wsl") or add a flag on the option to
mark WSL, and then update the install handler that processes the
"install-ollama" branch to detect that key/flag and run the WSL-specific startup
sequence (mirror the existing ollama branch behavior: do NOT set
OLLAMA_HOST=0.0.0.0 and do NOT start the auth proxy). Ensure you reference
isWsl(), the option key "install-ollama" (and new "install-ollama-wsl" or
option.flag), and the install/startup handler that launches `ollama serve` so
the correct WSL-safe startup path is used after installation.
- Around line 5366-5408: The Windows-host flow pins the resolved Ollama host
(via
switchToWindowsOllamaHost/awaitWindowsOllamaReady/setupWindowsOllamaWith0000Binding)
but when selectAndValidateOllamaModel returns outcome === "back-to-selection" we
never clear or recompute that resolution, so subsequent choices still use the
Windows host; fix this by clearing the cached/resolved host before continuing
selectionLoop (e.g., call a new resetResolvedOllamaHost helper or explicitly
unset the variable/env that getLocalProviderBaseUrl and getOllamaModelOptions
read) immediately before the continue selectionLoop after result.outcome ===
"back-to-selection" so provider/endpointUrl are recomputed on the next
selection.
- Around line 4710-4720: The recovered provider name "ollama" can refer to the
Windows-host action but this menu only exposes
"start-windows-ollama"/"install-windows-ollama", so update the options
construction in the hasWindowsOllama block to also add an alias entry keyed as
"ollama" that points to the same windowsOllamaLabel (i.e., push both { key:
"start-windows-ollama", label: windowsOllamaLabel } and { key: "ollama", label:
windowsOllamaLabel }), or alternatively adjust providerNameToOptionKey() to map
the recovered "ollama" to "start-windows-ollama"; reference the options array,
windowsOllamaLabel, the "start-windows-ollama" key and providerNameToOptionKey()
so the non-interactive recovery path will find the Windows-host action.
---
Nitpick comments:
In `@src/lib/local-inference.ts`:
- Around line 434-463: Add unit tests for getOllamaModelOptions covering two
host scenarios: (1) call setResolvedOllamaHost(OLLAMA_HOST_DOCKER_INTERNAL),
mock the capture used by getOllamaModelOptions (or pass a runCaptureImpl) to
return empty for the /api/tags endpoint and assert the function returns [] and
does not call the "ollama list" fallback (e.g. by having the list capture throw
or record calls); and (2) call setResolvedOllamaHost(OLLAMA_LOCALHOST), mock
capture so the /api/tags response is empty but the "ollama list" capture returns
a known value, then assert getOllamaModelOptions returns the parsed list (use
parseOllamaList expected output). Ensure tests reset the resolved host after
each case and use the getOllamaModelOptions/runCaptureImpl, parseOllamaTags,
parseOllamaList symbols to locate and wire mocks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 1e66f20d-f9c5-4691-bd1c-956310c66f18
📒 Files selected for processing (3)
src/lib/local-inference.tssrc/lib/onboard-windows-ollama.tssrc/lib/onboard.ts
Signed-off-by: zyang-dev <267119621+zyang-dev@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
src/lib/onboard.ts (1)
4772-4813:⚠️ Potential issue | 🟠 Major | ⚡ Quick winNon-interactive recovery still fails for recorded
ollama-localwhen only Windows-host actions are presentOn Line 4772, recovered
ollama-localmaps toollama, but when the menu only containsstart-windows-ollama/install-windows-ollama(Line 4711 onward), Line 4809 hard-fails with “Requested provider 'ollama' is not available.”
Please alias recoveredollamato an available Windows-host action before this availability check.Proposed fix
if (!providerKey) { const recordedProvider = readRecordedProvider(sandboxName); const hasNimContainer = !!readRecordedNimContainer(sandboxName); const recoveredKey = providerNameToOptionKey(recordedProvider, { hasNimContainer }); if (recoveredKey) { + let resolvedRecoveredKey = recoveredKey; + if ( + resolvedRecoveredKey === "ollama" && + !options.some((o) => o.key === "ollama") + ) { + const windowsFallback = options.find( + (o) => + o.key === "start-windows-ollama" || o.key === "install-windows-ollama", + ); + if (windowsFallback) { + resolvedRecoveredKey = windowsFallback.key; + } + } // Refuse to silently switch providers behind the user's back; if // the previously-recorded one is gone, surface the recorded value // so the user can fix the dependency or override via env var. - if (!options.some((o) => o.key === recoveredKey)) { + if (!options.some((o) => o.key === resolvedRecoveredKey)) { console.error( ` Recorded provider '${recordedProvider}' is not available in this environment.`, ); console.error( " Set NEMOCLAW_PROVIDER explicitly, or restore the missing local-inference dependency.", ); process.exit(1); } - providerKey = recoveredKey; + providerKey = resolvedRecoveredKey; recoveredFromSandbox = true; recoveredModel = readRecordedModel(sandboxName);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/onboard.ts` around lines 4772 - 4813, The recovery path sets providerKey (from recoveredKey or "build") and then looks up selected via options.find; when recovered/translated providerKey === "ollama" we must also accept Windows-host actions (e.g., "start-windows-ollama" or "install-windows-ollama") if those are present in options. Modify the logic around providerKey/selected (the block that uses providerKey, options, and selected) to, before the final error, if providerKey === "ollama" and options does not contain key "ollama" but does contain either "start-windows-ollama" or "install-windows-ollama", alias providerKey to the available Windows-host key (prefer start- over install- if both exist) so selected can be resolved; keep the existing special-case for "install-ollama" unchanged.
🧹 Nitpick comments (1)
src/lib/onboard.ts (1)
4574-5471: Run the onboarding E2E trio for this coresrc/lib/onboard.tsflow changeGiven the WSL provider menu/state-machine changes in this core path, it’s worth running the recommended workflow matrix before merge:
cloud-e2e,sandbox-operations-e2e,rebuild-openclaw-e2e.As per coding guidelines:
src/lib/onboard.ts— “E2E test recommendation: cloud-e2e, sandbox-operations-e2e, rebuild-openclaw-e2e”.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/onboard.ts` around lines 4574 - 5471, The change in src/lib/onboard.ts (setupNim and its WSL/provider state machine) requires running the three recommended E2E suites: cloud-e2e, sandbox-operations-e2e, and rebuild-openclaw-e2e against this branch; run each suite locally/CI, exercise WSL provider scenarios (WSL Ollama vs Windows-host Ollama, install/start/switch/restart flows), verify provider selection, model recovery, nim-local start/pull/health paths, and that prompts/transitions in setupNim behave as expected, record and attach the passing test logs to the PR (or note failures and fix regressions before merging).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/lib/onboard-windows-ollama.ts`:
- Around line 136-142: launchAndAwaitWindowsOllama currently discards the result
of runCapture so PowerShell Start-Process failures become a 30s readiness
timeout; change it to capture the runCapture result (call site:
launchAndAwaitWindowsOllama, variables: watcherPath, launchScript, runCapture)
and if runCapture indicates an error (non-zero exit or thrown error) immediately
surface that error (throw or return false) instead of calling
awaitWindowsOllamaReady(); only call awaitWindowsOllamaReady() when runCapture
succeeded so launch failures are reported promptly.
---
Duplicate comments:
In `@src/lib/onboard.ts`:
- Around line 4772-4813: The recovery path sets providerKey (from recoveredKey
or "build") and then looks up selected via options.find; when
recovered/translated providerKey === "ollama" we must also accept Windows-host
actions (e.g., "start-windows-ollama" or "install-windows-ollama") if those are
present in options. Modify the logic around providerKey/selected (the block that
uses providerKey, options, and selected) to, before the final error, if
providerKey === "ollama" and options does not contain key "ollama" but does
contain either "start-windows-ollama" or "install-windows-ollama", alias
providerKey to the available Windows-host key (prefer start- over install- if
both exist) so selected can be resolved; keep the existing special-case for
"install-ollama" unchanged.
---
Nitpick comments:
In `@src/lib/onboard.ts`:
- Around line 4574-5471: The change in src/lib/onboard.ts (setupNim and its
WSL/provider state machine) requires running the three recommended E2E suites:
cloud-e2e, sandbox-operations-e2e, and rebuild-openclaw-e2e against this branch;
run each suite locally/CI, exercise WSL provider scenarios (WSL Ollama vs
Windows-host Ollama, install/start/switch/restart flows), verify provider
selection, model recovery, nim-local start/pull/health paths, and that
prompts/transitions in setupNim behave as expected, record and attach the
passing test logs to the PR (or note failures and fix regressions before
merging).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 0a201d06-0cea-4acd-81ce-4e831304f12b
📒 Files selected for processing (3)
src/lib/onboard-windows-ollama.tssrc/lib/onboard.tstest/get-ollama-model-options.test.ts
…ative on recovery Signed-off-by: zyang-dev <267119621+zyang-dev@users.noreply.github.com>
Signed-off-by: zyang-dev <267119621+zyang-dev@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/lib/onboard.ts (1)
4770-4799:⚠️ Potential issue | 🟠 Major | ⚡ Quick winRecorded
ollama-localcan still auto-switch to the Windows daemon.
providerNameToOptionKey()always recoversollama-localas"ollama", and this branch only checks key availability. On WSL, if the saved provider was WSL Ollama but the only reachable daemon is alreadyhost.docker.internal, the recovered"ollama"path now succeeds and silently changes the daemon/model cache instead of failing loud.Suggested guard
const recoveredKey = providerNameToOptionKey(recordedProvider, { hasNimContainer }); if (recoveredKey) { + const recoveredWouldSwitchOllamaHost = + isWsl() && + recordedProvider === "ollama-local" && + ollamaHost === OLLAMA_HOST_DOCKER_INTERNAL; + if (recoveredWouldSwitchOllamaHost) { + console.error( + " Recorded provider 'ollama-local' is not available in this environment.", + ); + console.error( + " Hint: Windows-host Ollama is reachable here; re-run with NEMOCLAW_PROVIDER=ollama to use it explicitly.", + ); + process.exit(1); + } // Refuse to silently switch providers behind the user's back; if // the previously-recorded one is gone, surface the recorded value // so the user can fix the dependency or override via env var. if (!options.some((o) => o.key === recoveredKey)) {Based on learnings: "Repo NVIDIA/NemoClaw preference: In WSL onboarding, do not remap a recorded 'ollama-local' (WSL Ollama) to Windows-host actions ('start-windows-ollama'/'install-windows-ollama'). Prefer fail-loud to avoid silently switching the actual daemon and model cache. If needed, provide guidance rather than aliasing."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/onboard.ts` around lines 4770 - 4799, The code currently treats a recovered provider of "ollama-local" as the generic recoveredKey "ollama" and may silently accept Windows-host options; modify the logic after computing recoveredKey to detect if recordedProvider === "ollama-local" and the only matching option(s) are Windows-host variants (e.g., keys "start-windows-ollama" or "install-windows-ollama") and, in that case, treat the recovered provider as unavailable and fail-loud (same behavior as the existing console.error + process.exit(1) branch) instead of accepting the Windows-host mapping; use the existing symbols readRecordedProvider, providerNameToOptionKey, recoveredKey, recordedProvider, options, winHostKey, sandboxName and continue to set providerKey/recoveredFromSandbox/recoveredModel only when a true non-Windows match exists.
🧹 Nitpick comments (1)
src/lib/onboard.ts (1)
4574-5482: Please run the onboarding E2Es on this branch.This change rewires core
src/lib/onboard.tsselection/recovery behavior across WSL, Windows-host Ollama, and rebuild paths. I'd runcloud-e2e,sandbox-operations-e2e, andrebuild-openclaw-e2ebefore merging.As per coding guidelines: "
src/lib/onboard.ts: This file contains core onboarding logic. Changes here affect the full sandbox creation and configuration flow. E2E test recommendation:cloud-e2e— full onboard + cloud inference;sandbox-operations-e2e— multi-sandbox lifecycle;rebuild-openclaw-e2e— workspace state survives rebuild."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/onboard.ts` around lines 4574 - 5482, Summary: The onboarding changes in setupNim touch WSL/Windows-host Ollama selection and recovery; please run full E2Es to validate behavior. Run the cloud-e2e, sandbox-operations-e2e, and rebuild-openclaw-e2e pipelines and verify selection/recovery flows around setupNim, especially branches using findReachableOllamaHost, windowsOllamaReachable, winOllamaLoopbackOnly, selectAndValidateOllamaModel, resetOllamaHostCache and nim-local flows; confirm that provider/model recovery from readRecordedProvider/readRecordedModel and non-interactive paths behave correctly across WSL vs Windows host, that start/install/switch Windows Ollama branches succeed, and that rebuild preserves sandbox state and recorded nimContainer behavior—if failures appear, add targeted fixes/logging and re-run the specific failing E2E until green.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@src/lib/onboard.ts`:
- Around line 4770-4799: The code currently treats a recovered provider of
"ollama-local" as the generic recoveredKey "ollama" and may silently accept
Windows-host options; modify the logic after computing recoveredKey to detect if
recordedProvider === "ollama-local" and the only matching option(s) are
Windows-host variants (e.g., keys "start-windows-ollama" or
"install-windows-ollama") and, in that case, treat the recovered provider as
unavailable and fail-loud (same behavior as the existing console.error +
process.exit(1) branch) instead of accepting the Windows-host mapping; use the
existing symbols readRecordedProvider, providerNameToOptionKey, recoveredKey,
recordedProvider, options, winHostKey, sandboxName and continue to set
providerKey/recoveredFromSandbox/recoveredModel only when a true non-Windows
match exists.
---
Nitpick comments:
In `@src/lib/onboard.ts`:
- Around line 4574-5482: Summary: The onboarding changes in setupNim touch
WSL/Windows-host Ollama selection and recovery; please run full E2Es to validate
behavior. Run the cloud-e2e, sandbox-operations-e2e, and rebuild-openclaw-e2e
pipelines and verify selection/recovery flows around setupNim, especially
branches using findReachableOllamaHost, windowsOllamaReachable,
winOllamaLoopbackOnly, selectAndValidateOllamaModel, resetOllamaHostCache and
nim-local flows; confirm that provider/model recovery from
readRecordedProvider/readRecordedModel and non-interactive paths behave
correctly across WSL vs Windows host, that start/install/switch Windows Ollama
branches succeed, and that rebuild preserves sandbox state and recorded
nimContainer behavior—if failures appear, add targeted fixes/logging and re-run
the specific failing E2E until green.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 838326b4-9db7-45ee-b6f4-acfe12d9193c
📒 Files selected for processing (2)
src/lib/onboard-windows-ollama.tssrc/lib/onboard.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- src/lib/onboard-windows-ollama.ts
Signed-off-by: zyang-dev <267119621+zyang-dev@users.noreply.github.com>
… switch to Windows-host Signed-off-by: zyang-dev <267119621+zyang-dev@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/lib/onboard.ts (2)
5539-5548:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winPrint the actual Ollama host in the WSL
ollamabranch.When Line 4883 labels this option as
Windows host:11434, this branch can still printUsing Ollama on localhost:11434just becauseisWsl()is true. That makes it unclear which daemon/model cache was actually selected.Suggested fix
if (isWsl()) { // WSL2 doesn't need the proxy — Docker can reach the host directly. - console.log(` ✓ Using Ollama on localhost:${OLLAMA_PORT}`); + const resolvedHost = getResolvedOllamaHost(); + const hostLabel = + resolvedHost === OLLAMA_HOST_DOCKER_INTERNAL + ? "host.docker.internal" + : "localhost"; + console.log(` ✓ Using Ollama on ${hostLabel}:${OLLAMA_PORT}`); } else {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/onboard.ts` around lines 5539 - 5548, The WSL branch prints a hardcoded "localhost" even when a different Ollama host was selected; change the log to use the actual resolved Ollama host variable (the one used to produce the "Windows host:11434" label) instead of "localhost". Update the message inside the isWsl() true branch and the proxy branch that calls startOllamaAuthProxy() to interpolate that resolved host value (alongside OLLAMA_PORT and OLLAMA_PROXY_PORT as appropriate) so the console shows the real daemon/model-cache host chosen.
4799-4944:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftRecompute Ollama probes/options after install/start actions.
ollamaHost,hasWindowsOllama,windowsOllamaReachable, and theoptionslist are all captured before Line 4961, but the new Windows-host branches can change that state and thencontinue selectionLoopfrom Line 5637. After a successful install/start, the next menu still reflects the pre-action state, so it can keep offeringinstall-windows-ollamaeven though Ollama is now installed/running and omit the newly validollama/start-windows-ollamapaths.Please rebuild the WSL/Windows Ollama probe state at the top of each loop iteration, or explicitly refresh it before re-entering the provider picker after those state-changing branches.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/lib/onboard.ts` around lines 4799 - 4944, The Ollama/vLLM probe and options are computed once (using hostCommandExists, findReachableOllamaHost, runCapture, isWsl, VLLM_PORT, OLLAMA_PORT, winOllamaLoopbackOnly, windowsOllamaReachable, etc.) but never refreshed after install/start actions before continuing the selectionLoop; extract that probe + options-building logic into a single function (e.g., refreshOllamaState or rebuildProviderOptions) that recomputes ollamaHost, ollamaRunning, hasWindowsOllama, winOllamaLoopbackOnly, windowsOllamaReachable, vllmRunning and the options array, and call it at the top of each iteration and immediately after any state-changing branch (the install/start-windows-ollama and related branches) before continue selectionLoop so the menu reflects the updated runtime state.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@src/lib/onboard.ts`:
- Around line 5539-5548: The WSL branch prints a hardcoded "localhost" even when
a different Ollama host was selected; change the log to use the actual resolved
Ollama host variable (the one used to produce the "Windows host:11434" label)
instead of "localhost". Update the message inside the isWsl() true branch and
the proxy branch that calls startOllamaAuthProxy() to interpolate that resolved
host value (alongside OLLAMA_PORT and OLLAMA_PROXY_PORT as appropriate) so the
console shows the real daemon/model-cache host chosen.
- Around line 4799-4944: The Ollama/vLLM probe and options are computed once
(using hostCommandExists, findReachableOllamaHost, runCapture, isWsl, VLLM_PORT,
OLLAMA_PORT, winOllamaLoopbackOnly, windowsOllamaReachable, etc.) but never
refreshed after install/start actions before continuing the selectionLoop;
extract that probe + options-building logic into a single function (e.g.,
refreshOllamaState or rebuildProviderOptions) that recomputes ollamaHost,
ollamaRunning, hasWindowsOllama, winOllamaLoopbackOnly, windowsOllamaReachable,
vllmRunning and the options array, and call it at the top of each iteration and
immediately after any state-changing branch (the install/start-windows-ollama
and related branches) before continue selectionLoop so the menu reflects the
updated runtime state.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 1b0d1a84-0b88-434d-b11a-85d40afabb5f
📒 Files selected for processing (1)
src/lib/onboard.ts
cv
approved these changes
May 1, 2026
12 tasks
miyoungc
added a commit
that referenced
this pull request
May 5, 2026
## Summary Catch up the docs for user-facing changes that landed over the weekend and today, so the published guidance matches current installer, onboarding, status, logs, local inference, rebuild backup behavior, the next docs version selector, and refreshed generated user skills. ## Related Issue None. ## Changes - Document WSL Windows-host Ollama onboarding actions, including use, start, restart, install, and `host.docker.internal` model pulls from #2800; clarify that onboard owns Ollama install and model pulls from #2952. - Document installer fail-fast behavior for non-TTY third-party software acceptance from #2706. - Update sandbox-name guidance and Brev deploy validation behavior from #2948. - Add `nemoclaw <name> logs --tail/--since` coverage from #2825. - Add global `nemoclaw status --json` coverage from #2822. - Document verified-gateway status behavior and non-zero degraded exits from #2884. - Clarify that rebuild stops before deleting the original sandbox when backup fails, including unreadable or root-owned state paths. - Bump docs switcher metadata from 0.0.33 to 0.0.34 without changing package versions or creating release tags. - Regenerate `.agents/skills/nemoclaw-user-*` from docs, including the new `nemoclaw-user-manage-sandboxes` generated skill and removal of the stale `nemoclaw-user-workspace` output. ## Type of Change - [ ] Code change (feature, bug fix, or refactor) - [ ] Code change with doc updates - [ ] Doc only (prose changes, no code sample modifications) - [x] Doc only (includes code sample changes) ## Verification - [ ] `npx prek run --all-files` passes - [ ] `npm test` passes - [ ] Tests added or updated for new or changed behavior - [x] No secrets, API keys, or credentials committed - [x] Docs updated for user-facing behavior changes - [x] `make docs` builds without warnings (doc changes only) - [x] Doc pages follow the [style guide](https://github.com/NVIDIA/NemoClaw/blob/main/docs/CONTRIBUTING.md) (doc changes only) - [ ] New doc pages include SPDX header and frontmatter (new pages only) --- <!-- DCO sign-off required by CI. Run: git config user.name && git config user.email --> Signed-off-by: Miyoung Choi <miyoungc@nvidia.com> Made with [Cursor](https://cursor.com) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded Ollama/local inference guidance with detailed WSL and Windows-host workflows, proxy/token behavior, and onboarding options * Standardized sandbox name validation and updated troubleshooting, CLI, and deploy docs to surface the rules and validation timing * Added/rewrote Manage Sandboxes, policy management, backup/restore, messaging channels, workspace persistence, and CLI selection guides * Refreshed quickstart/Hermes guidance, skill mappings, and bumped docs version to 0.0.34 <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds Windows-host Ollama lifecycle actions (Use, Start, Restart, Install) to the WSL
nemoclaw onboardinference menu via PowerShell interop. Lets users on WSL2 run Ollama on the Windows side and reach it from the sandbox without manually configuringOLLAMA_HOST=0.0.0.0, kill+restart cycles, or learning that wslrelay holds 127.0.0.1.Changes
Use,Restart,Start,InstallWindows-host Ollama (label flips onwindowsOllamaReachable/winOllamaLoopbackOnly/hasWindowsOllama).src/lib/onboard-windows-ollama.tsowns the Windows-host action helpers: install, kill watcher-then-daemon, capture watcher path, persistOLLAMA_HOSTenv, launch + await ready, switch (cache pin only).OLLAMA_HOST=0.0.0.0:11434in both User-scope registry and the current PowerShell session so the installer's auto-spawned daemon binds correctly with no kill+relaunch.stdio: inheritthrough WSL interop block-buffersWrite-Hostfor minutes.curl --connect-timeout 2 --max-time 5probes againsthost.docker.internal:11434/api/tagsso a half-state listener cannot eat the readiness budget.[Y/n]to nudge users toward the Windows-host path.selectAndValidateOllamaModelfrom three near-duplicate inline loops insetupNim.getOllamaModelOptionsno longer falls back to the localollama listCLI when the resolved host is non-loopback (would surface WSL models when targeting the Windows-host daemon, breaking validation).ollama servewhen the installer's systemd unit is already up so journalctl logs stayintact.
ollama-localis fail-loud rather than auto-substituting the Windows-host daemon. Two cases:start-windows-ollama/install-windows-ollamaare present: print aNEMOCLAW_PROVIDER=…hint.host.docker.internal: refuse before the availability check finds the menu'sollamakey (which now points at Windows-host) and silently swaps daemon/model cache.launchAndAwaitWindowsOllamachecks PowerShell exit code and surfaces stderr instead of waiting 30s for a readiness probe to fail.installOllamaOnWindowsHostlogs spawn errors (e.g. powershell.exe missing) and guards stdio listeners so the install path doesn't crash on hosts where the spawn returns no streams.getOllamaModelOptionshost-pinned behavior (non-loopback empty/api/tagsreturns[]; loopback falls back toollama list).Type of Change
Verification
npx prek run --all-filespassesnpm testpassesmake docsbuilds without warnings (doc changes only)AI Disclosure
Signed-off-by: zyang-dev 267119621+zyang-dev@users.noreply.github.com
Summary by CodeRabbit
New Features
Improvements
Tests