fix(onboard): render truthful Ollama status in the inference menu

[Dongni-Yang]

Summary

Interactive onboarding gated the local daemon probes on the shared-gateway route preflight, so any unrelated registry route on the same gateway silently hid a running Ollama or vLLM daemon from the step [3/8] inference menu (no — running suffix, no detection banner). Interactive runs now always probe — route conflicts stay enforced at selection time via assertRouteCompatible — and an installed-but-stopped daemon renders the action label Start local Ollama (WSL:11434) instead of a status-style label that reads as a reachability claim.

Related Issue

Refs #6750

Changes

• src/lib/onboard/setup-nim-provider-discovery.ts: stop ANDing canProbeRoute into probeOllama/probeVllm on the interactive path; non-interactive runs keep the preflight gate. Selection-time containment (assertRouteCompatible in guardProviderInferenceRouteSelection) is unchanged and remains the enforcement point for shared-gateway route conflicts.
• src/lib/onboard/ollama-install-menu.ts: render Start local Ollama (<host>) when the daemon is installed but not running; the running label (Local Ollama (<host>) — running (suggested)) is unchanged. The entry stays because selecting it is the deliberate auto-start path — suppressing it would leave WSL users on native Docker with no in-wizard path to a local Ollama.
• src/lib/onboard/setup-nim-flow.test.ts: update the probe-gating contract test to the new interactive behavior.
• src/lib/onboard/setup-nim-provider-discovery.test.ts (new) and src/lib/onboard/ollama-install-menu.test.ts: regression tests that fail without the fix, plus guards pinning the retained non-interactive gate.
• docs/get-started/windows-preparation.mdx, docs/inference/set-up-ollama.mdx: state the Docker Desktop WSL integration requirement for the Windows-host Ollama path and describe the interactive re-prompt accurately (the third symptom in [macOS][Onboard] onboard inference menu: Ollama items display incorrect status on macOS and WSL2 #6750 — the (requires Docker Desktop WSL integration) suffix — is working as designed; the expected (loopback only — switch to 0.0.0.0) wording never existed in the codebase).

Type of Change

• Code change (feature, bug fix, or refactor)
• Code change with doc updates
• Doc only (prose changes, no code sample modifications)
• Doc only (includes code sample changes)

Quality Gates

• Tests added or updated for changed behavior
• Existing tests cover changed behavior — justification:
• Tests not applicable — justification:
• Docs updated for user-facing behavior changes
• Docs not applicable — justification:
• Sensitive paths changed (security, policy, credentials, preflight, onboarding, inference, runner, sandbox, or messaging)
• Sensitive-path review completed or maintainer-approved waiver recorded — reviewer/approval link/justification:
• Non-success, skipped, or missing CI check accepted by maintainer — check name, approval link, and follow-up issue:

Verification

• PR description includes the DCO sign-off declaration and every commit appears as Verified in GitHub
• Normal pre-commit, commit-msg, and pre-push hooks passed, or npm run check:diff passed when hooks were skipped or unavailable
• Targeted behavior tests pass for the current change set, or tests are marked not applicable above — command/result or justification: npx vitest run --project cli src/lib/onboard/ — 294/295 files pass (2905 tests); new regression tests confirmed red before the fix and green after; the one failing file (created-sandbox-finalization.test.ts, 2 tests, [All Platforms][Onboard] --fresh re-onboard keeps the old in-sandbox model — nemoclaw status shows the new model while the agent still runs the previous one #6311) fails identically on pristine upstream/main and is unrelated
• Applicable broad gate passed — npm test for broad runtime/test-harness changes; npm run check for repo-wide validation/coverage changes — command/result:
• Quality Gates section completed with required justifications or waivers
• No secrets, API keys, or credentials committed
• npm run docs builds without warnings (doc changes only) — 0 errors; the 2 reported warnings are pre-existing (identical count on a build without this change)
• Doc pages follow the style guide (doc changes only)
• New doc pages include SPDX header and frontmatter (new pages only)

---

Signed-off-by: Dongni Yang dongniy@nvidia.com

Summary by CodeRabbit

• New Features

  • Interactive onboarding now continues local provider discovery even when route conflicts are detected.

• Bug Fixes

  • Improved provider detection and probing logic for interactive vs non-interactive onboarding scenarios.
  • Updated the Ollama menu label to clearly show “Start local Ollama” (with the correct host) when Ollama isn’t running.

• Documentation

  • Refined Windows/WSL Ollama setup guidance, including Docker Desktop WSL integration requirements and handling the express prompt (including NEMOCLAW_NO_EXPRESS=1).

[github-code-quality]

Code Coverage Overview

Languages: TypeScript

TypeScript / code-coverage/plugin

The overall coverage remains at 96%, unchanged from the main branch.

TypeScript / code-coverage/cli

The overall coverage in the fix/6750-ollama-menu... branch remains at 79%, unchanged from the main branch.

Show a code coverage summary of the most impacted files.

File	main 3de1de6	fix/6750-ollama-menu... c92259b	+/-
src/lib/messagi.../persistence.ts	90%	89%	-1%
src/lib/onboard...install-menu.ts	88%	88%	0%
src/lib/state/gateway.ts	88%	90%	+2%
src/lib/state/m...-acquisition.ts	77%	80%	+3%

---

_{Updated July 13, 2026 08:41 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: decab5ab-0e00-4639-9a04-a91a17c364dd

📥 Commits

Reviewing files that changed from the base of the PR and between 606690e and c92259b.

📒 Files selected for processing (1)

• docs/get-started/windows-preparation.mdx

🚧 Files skipped from review as they are similar to previous changes (1)

• docs/get-started/windows-preparation.mdx

---

📝 Walkthrough

Walkthrough

Interactive onboarding now permits local provider probes despite route conflicts, while non-interactive runs retain gating. Ollama’s stopped-state menu label and Windows/WSL remediation guidance are updated with corresponding tests.

Changes

Onboarding behavior

Layer / File(s)	Summary
Interactive provider discovery src/lib/onboard/setup-nim-provider-discovery.ts, src/lib/onboard/setup-nim-provider-discovery.test.ts, src/lib/onboard/setup-nim-flow.test.ts	Interactive provider probes remain enabled despite route conflicts; non-interactive probing continues to respect route preflight checks, with updated coverage.
Ollama menu and Windows guidance src/lib/onboard/ollama-install-menu.ts, src/lib/onboard/ollama-install-menu.test.ts, docs/inference/set-up-ollama.mdx, docs/get-started/windows-preparation.mdx	Stopped Ollama uses a “Start local Ollama” label, and Windows-host Ollama remediation and WSL integration requirements are clarified.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• NVIDIA/NemoClaw#4089: Related Ollama onboarding behavior for installed but stopped Windows-host Ollama.
• NVIDIA/NemoClaw#4416: Related Ollama onboarding menu behavior and Docker Desktop WSL integration guidance.

Suggested labels: bug-fix, area: cli

Suggested reviewers: cv, cjagwani, brandonpelfrey, ericksoa, prekshivyas

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: improving Ollama status rendering in the onboarding/inference menu.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/6750-ollama-menu-status

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-6753.docs.buildwithfern.com/nemoclaw

[github-actions]

E2E Advisor Recommendation

Required E2E: onboard-repair, onboard-resume, cloud-onboard
Optional E2E: None

Dispatch hint: onboard-repair,onboard-resume

Workflow run

Full advisor summary

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• onboard-repair: Required by the deterministic lifecycle-state risk plan. Provider discovery participates in recovery and route reconstruction; live repair must prove state converges after interrupted onboarding.
• onboard-resume: Required by the deterministic lifecycle-state risk plan. The changed recovery-aware provider discovery and local inference probe behavior can affect resumed onboarding state and provider selection.
• cloud-onboard (high): Changed onboard, trace timing, scorecard, or E2E workflow code can affect cloud onboard wall-clock behavior and should refresh the trusted cloud-onboard trace timing signal.

Optional E2E

• None.

New E2E recommendations

• windows-wsl-onboarding (medium): Current required resume and repair coverage validates recovery, but does not specifically exercise the interactive local-provider menu with a stopped/running Ollama daemon under WSL and a same-gateway route conflict.
  • Suggested test: Add a live WSL onboarding E2E scenario that verifies interactive discovery still reports local Ollama status when a route conflict exists, labels a stopped daemon as a start action, and keeps Windows-host actions unavailable with native Docker Engine.

Dispatch hint

• Workflow: e2e.yaml
• jobs input: onboard-repair,onboard-resume

[github-actions]

PR Review Advisor — No blocking findings

Merge posture: No blocking advisor findings
Primary next action: No advisor follow-up required beyond maintainer review.
Findings: 0 required · 0 warnings · 0 optional suggestions
Since last review: 0 prior items resolved · 0 still apply · 0 new items found

Workflow run details

This is an automated review. Required findings need action before merge. Warnings and optional suggestions do not require a response or follow-up. A human maintainer makes the final merge decision.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

src/lib/onboard/setup-nim-provider-discovery.test.ts (1)

31-61: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Cover the non-interactive vLLM gate.

The implementation has independent non-interactive Ollama and vLLM branches, but these tests only exercise the non-interactive Ollama intent. Add blocked and allowed vLLM cases so the probeVllm route-gating branch cannot regress silently.

As per path instructions, tests should provide behavioral confidence for each changed path.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/onboard/setup-nim-provider-discovery.test.ts` around lines 31 - 61,
Add corresponding blocked and allowed non-interactive vLLM tests alongside the
existing Ollama cases in the setup provider discovery test suite. Configure the
non-interactive provider as vLLM and assert probeVllm is false when
canProbeRoute returns false and true when it returns true, preserving the
existing dependency and setup patterns.

Source: Path instructions

src/lib/onboard/setup-nim-flow.test.ts (1)

358-386: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Exercise selection-time conflict enforcement through the public boundary.

This test only proves that canProbeRoute is not called; its selection stub chooses nvidia-prod, and no local-provider rejection through assertRouteCompatible is exercised. Add a local selection case that remains blocked by a route conflict while retaining the probe assertions.

As per path instructions, tests should verify observable behavior through the public boundary rather than rely on mock-call assertions.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/onboard/setup-nim-flow.test.ts` around lines 358 - 386, Update the
test around createSetupNim and setupNim to exercise a conflicting local-provider
selection that is rejected through the public setup flow by
assertRouteCompatible, while preserving the interactive discovery behavior and
expected detect:true:true probe event. Replace the canProbeRoute call-count
assertion with observable outcome assertions showing local selection remains
blocked, and retain the remote-selection setup only as needed to reach the
public boundary.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/get-started/windows-preparation.mdx`:
- Line 165: Update the Windows Ollama onboarding guidance in the surrounding
paragraph to scope express install to Docker Desktop WSL integration being
available. Explicitly direct users running native Docker Engine inside WSL to
use the WSL Ollama instance and avoid the Windows-host path.

---

Nitpick comments:
In `@src/lib/onboard/setup-nim-flow.test.ts`:
- Around line 358-386: Update the test around createSetupNim and setupNim to
exercise a conflicting local-provider selection that is rejected through the
public setup flow by assertRouteCompatible, while preserving the interactive
discovery behavior and expected detect:true:true probe event. Replace the
canProbeRoute call-count assertion with observable outcome assertions showing
local selection remains blocked, and retain the remote-selection setup only as
needed to reach the public boundary.

In `@src/lib/onboard/setup-nim-provider-discovery.test.ts`:
- Around line 31-61: Add corresponding blocked and allowed non-interactive vLLM
tests alongside the existing Ollama cases in the setup provider discovery test
suite. Configure the non-interactive provider as vLLM and assert probeVllm is
false when canProbeRoute returns false and true when it returns true, preserving
the existing dependency and setup patterns.

🪄 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: 256064f7-d897-426a-9b9b-182c9ebe9c21

📥 Commits

Reviewing files that changed from the base of the PR and between 2c225be and 606690e.

📒 Files selected for processing (7)

• docs/get-started/windows-preparation.mdx
• docs/inference/set-up-ollama.mdx
• src/lib/onboard/ollama-install-menu.test.ts
• src/lib/onboard/ollama-install-menu.ts
• src/lib/onboard/setup-nim-flow.test.ts
• src/lib/onboard/setup-nim-provider-discovery.test.ts
• src/lib/onboard/setup-nim-provider-discovery.ts

[cjagwani]

Exact-head maintainer review complete on c92259b. CI is green, all commits are Verified with PR-body DCO, the trusted PR Review Advisor reports merge_as_is, and no unresolved actionable threads remain. Security review across the nine categories found no credential, input-validation, authorization, dependency, logging, cryptography, configuration, testing, or holistic-posture regression: interactive local-daemon probing only drives truthful menu status, while route compatibility is still enforced when a provider is selected. The added tests preserve the non-interactive fail-closed route gate and cover stopped-daemon labels.